From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from outbound.pv.icloud.com (pv-2002l-snip4-2.eps.apple.com [57.103.64.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7D7B6381EBC for ; Fri, 21 Aug 2026 17:10:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=57.103.64.163 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787332233; cv=none; b=BQNvRM2wddDGbNF90puv3I/MXWoe83BXXpMvWO+ZKXq62H1VEWDzwA3EVyGq2pMdVIx4MhcWw/PVomXXdcUZ3excxqm/EjaZmHwWM3q3KKiX69C3vnUVhrqvkHukdNo/YiFlpm2vK+G75zrA29YjJ9Kjxucsf6AgDVyGYeyP6VQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787332233; c=relaxed/simple; bh=QowjyGmoL0B3kOmDLt447qjuts4TXdfzyXYIf1120Yo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ES2aT9FghzzxfmCgt23stfo40hIk1A+uiY0AddkfQ8Y6REVhEnTUrFONnLsVowk1PyrfNnvKf/qnaay9VKEHg8vFxydG9N7tCdPLff+X5XoqKJMhkxRWSm9GhKDYjfPdV8nfOnU3xIQ+Ma3RVKlwbHk+n6i/aBN+06gwA0Q0T5g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=me.com; spf=pass smtp.mailfrom=me.com; dkim=pass (2048-bit key) header.d=me.com header.i=@me.com header.b=gEYoKaMJ; arc=none smtp.client-ip=57.103.64.163 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=me.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=me.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=me.com header.i=@me.com header.b="gEYoKaMJ" Received: from outbound.pv.icloud.com (unknown [127.0.0.2]) by p00-icloudmta-asmtp-us-west-1a-20-percent-2 (Postfix) with ESMTPS id 4D654180035B; Fri, 21 Aug 2026 17:10:26 +0000 (UTC) X-ICL-RepId: 01a0254d-6cb4-7d74-aa23-6d7ba8a8508a X-ICL-Out-Info: HUtFAUMHWwJACUgBTUQeDx5WFlZNRAJCTQhABkMAWBxBDkkdXwVaEhVdRVUIRRlTHhccRgxFGVswVB0dDlgGEhZdRV4IGQhdHRkKUFAGWxIYXBRcUFgeRhJWDV0JGRtEXlAbXwJCDxwTVhUTHUMZDysISgRDB0UCXgslEwlTVl8VFxtcABcGWxQERAFdBV0CSAtJAloGWwNJF00AXQVSAl0IVVUIRRlTHhccRgxFGVswVB0dDlgGDFBNAUMICgJRHFYNVw== Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai; t=1787332232; x=1789924232; bh=y7vmQEH+EXJnCGy6NDM0LcFuCB9ULXv4xHDAVnQjTbw=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:x-icloud-hme; b=gEYoKaMJPVootcGsoImNWYqlHnP6cRmimFHOK4FBH1CWqeOM+7gVH9HLKHihCLNOZKWLGvD9kuyhJMYaIMt8ZLU8oElqTkAmhwMC4qrE9pHj2wrLLEYuTcPXNGMeCixS0t86lOntAOHVdEiLV9MYcs09iOIfGK8Bh+eOp5cTQ9NWnTegkwnF4YJ4lBfJbkdk6Z2q3HEzMS4rCUbnO/GbIiVRtLRw5jP4Xm5JHFEXaGkf98inQPUlI3oyQ6PJJQTBKqoMW5D3D7p0/NVFaV30T2j5czxSOKsyUlqS3DdGBODyGkyNUP08FEF4PqPGxI652+DKCepoVM3MJd0ntXR5og== Received: from ncore (unknown [17.156.192.29]) by p00-icloudmta-asmtp-us-west-1a-20-percent-2 (Postfix) with ESMTPSA id 7AA1A1802180; Fri, 21 Aug 2026 17:10:23 +0000 (UTC) From: Ferran Duarri To: David Hildenbrand , Lorenzo Stoakes , Zi Yan , Andrew Morton Cc: Johannes Weiner , Baolin Wang , Ryan Roberts , Barry Song , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: thp: default defrag mode to defer+madvise Date: Fri, 21 Aug 2026 19:10:17 +0200 Message-ID: <20260821171019.530290-1-ferran.duarri@me.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <06f5eea7-c6e7-49ed-8f45-0c6c86a04c26@kernel.org> References: <20260820190825.221308-1-ferran.duarri@me.com> <06f5eea7-c6e7-49ed-8f45-0c6c86a04c26@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Proofpoint-ORIG-GUID: g5bQ3r4UL7hR7-uJueVRq5EREg00XwRO X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODIxMDEzNSBTYWx0ZWRfXylG5i1v7Ltdi IxkNdAL6kaSEBiFVLG4wWz0Scay4VsqGnB6BbsczPKOvJz3gTovt5xMd92HVohIF8Ow2kr7DkDA PJjthsNo+n4CjvKGlQJk0czcJ0Nq+oSruT3vZ2C1H0UlW/JEPSNIYM3REHC1dfyjhziUGYEULSh hiU5tkYaBI3rSmNArOAA59d41JGcoUsCAbwSLlIPW04tjcudzcD6dbCj1QRKmhQvjBvDdWmGysY 3b34EFyRRzm1IO0jey8JTXusXIR6TlkPQgNwx8YGaBs7xI6xpH/+sWil7/0xUtmj7ER5lC77A9V eALVKzXVBr3L21l0RsNYrvE8ObNB1EglOn8ohyIvo9rF6ClajOxiAmPyQ7A8H8= X-Proofpoint-GUID: g5bQ3r4UL7hR7-uJueVRq5EREg00XwRO X-Authority-Info-Out: v=2.4 cv=VMPQXtPX c=1 sm=1 tr=0 ts=6a888683 cx=c_apl:c_pps:t_out a=aW9mcIavGNWWFvFFKOxBSA==:117 a=aW9mcIavGNWWFvFFKOxBSA==:17 a=IkcTkHD0fZMA:10 a=Sv0fKeRqtYgA:10 a=x7bEGLp0ZPQA:10 a=B9nqV3Rn1-QA:10 a=VkNPw1HP01LnGYTKEx00:22 a=PCHdVTuO9_M3hTcQpgcA:9 a=QEXdDO2ut3YA:10 X-JNJ: AAAAAAAB7+eZj6DEaCgCBjELS8/Km6w2M1nLXrEPw5dfxgis1/HffaeQBMdKktdOnwp7+H9hQMSdhB46/YOEOqIoOtVAT0svE8vKMdvXqXjSpouOm6R01Gm/ml+BEZaug7P+NAviyzKYyiy+lVrOfh7nIA32rpnK7FpBifiiBz66+LlGXN2n2Ye5Sd1coL+sJ4ZESehT1UQI5jcy9mSX2Wdib0h2tt01JHRCBpPCqb++o8KoVLYQ8kqTBJ+XnLocMA+aQqhNkOA3EtinYQMjDnFAfqgaJRK50suxX4XDeB9QA3mlbyxI0J9Tpb+yOlwYODiOPpragrVyVFQjw/chL6eIBQPM/7EI3rI149ZE60eXAwxt7IW4D6h2QXvWi74AxODQlJ12TcCu22kV+9AIFEeCpwaJENwXl4lMaSpbMBezSPbBTXHmgAFs9xTeyt//majrxxW75P7lJSQLrybsaP4ez3fSE/rcrwoqXzmBilr2V6DauLPPazKYdUj/kn0FVuHlYgDO6vCmmId3Ze10hfjHFSpPEjM5oFuanSKf7Ol863AlQT2ww+iK+OvzGLY429Cx73jR07wa3jJcDQDoMMT2NE4EO5gyBUAAAs8sX0HgVRkI/HbjqMQH8fCpmLlc/pRtN2IC0nDhVO7kKLnAL7GNwFmREf0ktDdalkRj3dwJsGZkC6pBasSeJ1IYr9Y9kjf6yzv3WGy5WqM8m2QoEpD1/lDZGYjNJikbU8rPAmortUPKFIdGXLXGddkophdaPBsvG1sdFxriOfwSiShVUialnbRxoqe2CQ+v7HstH8TSCxTn6upXoHGLYEcnXBmSdT1XLITy5uOPB2QlajkBlTRGpxpalSfrAVM3PoQ+pc0Z9jE7ZXkFEmi222UZuLG04dFZM1PYxl4jlqlnFNGzOrzejYKBPivp47KcLPzrrElqwKZWwqvkrPZt49vhMPxRmOdYjiyXjxZLMMrWL+4yCM+09gK+rAJ tkYsJ7A09OaI5ze+sS+m+8uKlSk+WB5J6jeJeZcBJ1sgmvvjTMI1lCKLr3rw6jBv72C+ofMfquHPTdR4MZxupcS/bSV6/GB/nQuymcvxYBlbreXlGag/OYLKkFdM6pk3BC4iGwTXvj/PEKWx5yKzJCL5200KDzVJBnVBNf5Y2pB1GRhhaGZqVox6N42rLfjs2UIm6Fmzdss9bGlUuxNPVCbGkRs+FcxuFK0NEVTf8OkHtPqrXIEZdyK98Ic5lhVwxznXyS6Dt1w== Please drop this one, and not for the reason you asked about. Your mail sent me back to read the code properly, and my commit message has the mechanism backwards. I claimed: > Paired with transparent_hugepage=always every anonymous fault > becomes eligible, and under memory pressure the faulting thread can > stall in compaction. That doesn't happen. In vma_thp_gfp_mask(), the current default: /* Only do synchronous compaction if madvised */ if (test_bit(TRANSPARENT_HUGEPAGE_DEFRAG_REQ_MADV_FLAG, ...)) return GFP_TRANSHUGE_LIGHT | (vma_madvised ? __GFP_DIRECT_RECLAIM : 0); A non-madvised fault gets GFP_TRANSHUGE_LIGHT with no reclaim flag at all, so it fails fast and cannot stall in direct compaction. The stall I described is only reachable from a MADV_HUGEPAGE region, and defer+madvise keeps __GFP_DIRECT_RECLAIM for exactly those regions: if (test_bit(TRANSPARENT_HUGEPAGE_DEFRAG_KSWAPD_OR_MADV_FLAG, ...)) return GFP_TRANSHUGE_LIGHT | (vma_madvised ? __GFP_DIRECT_RECLAIM : __GFP_KSWAPD_RECLAIM); So the patch removes no stall. What it actually changes is the other branch: non-madvised faults gain __GFP_KSWAPD_RECLAIM, which they did not have. That is strictly more background work, waking kswapd and kcompactd on failed THP allocations across every anonymous fault under THP=always. The patch does close to the opposite of what it claims, and on a fragmented machine it is a plausible regression rather than an improvement. transhuge.rst says the same thing I should have read before writing the commit message: madvise "will enter direct reclaim like always but only for regions that are have used madvise(MADV_HUGEPAGE)". Zi Yan, that also answers your question, and you were right to ask it: the extra kswapd and kcompactd work you identified is the real effect of the patch, not a side cost of it. One correction to my own patch while I am here. I wrote that the machine could not testify: thp_fault_fallback 0 across 60682 faults, compact_stall 0. That was true when I sent it and is not true now. Same box, THP=always, 64 GB, after a few hours with a 27B model resident: thp_fault_alloc 213690 thp_fault_fallback 22145 compact_stall 3762 compact_fail 1926 So it does reach the fallback path, it just had not yet. I am not offering that as evidence for anything: it was collected with defer+madvise already in effect, so it says nothing about what madvise would have done, and defrag is writable at runtime, so the A/B costs nothing. If I get something worth showing, it will be a fresh patch with numbers in it, not this one. Lorenzo, no argument on the patch. It is wrong for the reason above and I would rather have found that before sending than after. On "distros can set as needed", that is the one part I would push back on, and it is the same thing David asked. They cannot, other than by writing to sysfs after boot. There is no Kconfig symbol for defrag; mm/Kconfig offers only the ALWAYS/MADVISE/NEVER enablement axis. There is no boot parameter either: setup_transparent_hugepage() sets TRANSPARENT_HUGEPAGE_FLAG and TRANSPARENT_HUGEPAGE_REQ_MADV_FLAG only, and thp_anon= is a different axis again. Grepping for what sets the DEFRAG bits at all outside the initialiser, it is defrag_store() and nothing else. So a distro that wants a different defrag default ships a sysfs unit, and anything faulting between subsys_initcall(hugepage_init) and that unit gets the compiled-in value. That may well be deliberate and sufficient. If it is not, a boot parameter is the cheap fix and I am happy to write it. Either answer is useful to me, and I would rather be told it is a non-problem than guess. Some context, offered as an explanation and not as an excuse. These patches come out of running large models locally: I maintain a custom kernel tree for my own inference workstation, and the changes in it accumulated there first, against a real workload rather than as ideas. I have started sending them upstream to put that pile in order and to find out which of them are actually correct rather than merely useful to me. This one is a fair sample of why that is worth doing, and of why the order I did it in was wrong: I posted while still testing, instead of testing and then posting. I am slowing the pace down and the rest stays local until it has had more than this one got. Thanks for the review. It caught a real error. Ferran