From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 D23F430DEA6 for ; Fri, 21 Aug 2026 16:53:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787331219; cv=none; b=EbiZ+j0BRkICgWU3grNd9b79rPi6bvs8kakyqK+Nh916OOW3c8CVBmBNHP4HCA2kFFG4ZN1Dn9KuiquugckyN8SdXkIltgRIZIa828A10qdSq6vZP3Hxs+uH2oeaCyr8dyRFFD2+vOOYzJCuGdqfCVHZr0oZFQogeR07+YaAOK8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787331219; c=relaxed/simple; bh=dnf1fBjWKoVq1sIM8J2BADNLg6Q2cPAEqQSqcbgWKnU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=W1TCVRYotwl0gRDd3R0EFSCqtUbVsiP0afu0u+d90W+mn7nDsDO88Nc4beLcs5gohhBUHBtNZZhrTtcmd7nYsCbMpM+y2bUkcpP7mDsXH11ELpolu42OX0rbKLvrMVAgEt7sF7Y6EawjooNvJIV/DVHQ2+TrFaREZCq37fs7Liw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=FkXHbN2C; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="FkXHbN2C" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4EF9A1F00ADE; Fri, 21 Aug 2026 16:53:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1787331215; bh=oo7PIGyyBJzzL+aXqmoxOMbS4o7tVVs0naaBSJhOIDI=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=FkXHbN2ClFbDdtrDXo2ivUD8W/tTJnzfs0/XqMoxNIjt3UMcm/XO75cSPaxsiB45m LnYhYy/iyGVtZvl6re2TGNCbbqVq6sU3QpVIpaTOCPcYN+6HveBlpkR3EPNPSgEtej AqhG3iHz8sbD1wU1IzzXoXF74UQKoMsNCinq1ShHGBkCQR70gPiiNESVA0cB0frMqX XUUnJZ4isYF5/ClqtgW+TSR+ZPVWImcGonCyX0Bj/aR/+YxFCAFaqfTG284/N2CqU9 /LiE/+yINR+IrK47B0gymORv93ZQusDOktlcXnzvvpmYdumZw1yX6fgEHgeGMx1NWr nilQX1mYNH8XQ== Date: Fri, 21 Aug 2026 17:53:30 +0100 From: "Lorenzo Stoakes (ARM)" To: Ferran Duarri Cc: Andrew Morton , David Hildenbrand , Zi Yan , 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 Message-ID: References: <20260820190825.221308-1-ferran.duarri@me.com> 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=us-ascii Content-Disposition: inline In-Reply-To: <20260820190825.221308-1-ferran.duarri@me.com> No. We don't randomly change core mm defaults like this especially not on the behest of AI schlop... On Thu, Aug 20, 2026 at 09:08:23PM +0200, Ferran Duarri wrote: > transparent_hugepage_flags unconditionally sets > TRANSPARENT_HUGEPAGE_DEFRAG_REQ_MADV_FLAG, so the built-in defrag mode > is always "madvise" regardless of which of CONFIG_TRANSPARENT_HUGEPAGE_ > ALWAYS or _MADVISE was selected. Those Kconfig options choose whether > THP is applied by default; they do not express a preference about how > hard the allocator should work to produce a huge page, yet the defrag > default is pinned as if they did. It's not pinned. Distros change these as they please. That's where any such change should be. > > In "madvise" mode a fault on a MADV_HUGEPAGE region performs direct > compaction in the fault path. Paired with transparent_hugepage=madvise > that is a bounded cost, since only regions that asked for it are Not really that bounded in practice. > affected. Paired with transparent_hugepage=always every anonymous fault > becomes eligible, and under memory pressure the faulting thread can > stall in compaction. What? No? > > "defer+madvise" keeps the same set of regions eligible for huge pages > and the same allocation attempt, but on failure it wakes kswapd and > khugepaged to compact in the background instead of doing it inline. The If we felt it was right to set this a default we would have... > fault proceeds with small pages and the region is collapsed later. This > is the configuration long recommended to users running THP=always with > large anonymous working sets, and it is a strictly weaker stall > guarantee to make the default. > > This changes only the compiled-in default; > /sys/kernel/mm/transparent_hugepage/defrag continues to accept every > existing mode, including the current "madvise" behaviour. None of this judstifies anything. > > No stall measurement is offered with this patch. On the machine that > prompted it the fault path never reaches direct compaction at all: > thp_fault_alloc is 60682 against thp_fault_fallback 0, and compact_stall > is 0, because memory has stayed abundant enough that no huge-page > allocation has had to fall back. That makes the box unable to testify > either way, and a number gathered under those conditions would measure > nothing. The argument above is a correctness one about which knob the > Kconfig choice is entitled to set, and it should be judged on that. This sentence is truly ludicrious...! Made me laugh a bit though which is something at least. > > Signed-off-by: Ferran Duarri You: - Only started posting patches yesterday - Have posted patches all over the kernel - Post walls of text that read exactly like they are AI-generated - Are trying to change a fundamental default, not as an RFC, not citing any actual workloads Go away and read: https://docs.kernel.org/process/coding-assistants.html https://docs.kernel.org/process/generated-content.html Then ideally just go away. We don't want AI slop patches from people who have no understanding of what they're changing, thanks! > --- > mm/huge_memory.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > index b118bcd392cb..749f669cca56 100644 > --- a/mm/huge_memory.c > +++ b/mm/huge_memory.c > @@ -63,7 +63,7 @@ unsigned long transparent_hugepage_flags __read_mostly = > #ifdef CONFIG_TRANSPARENT_HUGEPAGE_MADVISE > (1< #endif > - (1< + (1< (1< (1< -- Cheers, Lorenzo