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 043EB42CB01 for ; Fri, 21 Aug 2026 16:41:52 +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=1787330517; cv=none; b=BXB8oNxZm1uhGG/d/6a6P9EZOaOnNX0YWB1S3z1bwBTURziFQWtXz5ZNnbuhKYiM0/ARY7gNu1EBM8RBycYaGzROqVs5xuISYzC9HJwzOYtbMbevrgXjb7HkDGzIoh7drfG31yqiBaLoEWIHafEBoxgOnr4unOqKjYbRaB3cYB8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787330517; c=relaxed/simple; bh=hQbSHL7d4CyN1bg44ZG54XMORTB2er5vY+vFUF6aIMw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=oXaZNMVuq0Ar8MnTNUKRF0vlosaTROpLvSwjG/CpPbMhWfrpLZJasw7VP7WKeglzlkrPQB1EGEPjPKvuTvx7CXuvHhzUgCOho2OAbfVw8ohTJ+FpJDA+LlEbWp6wKkqxCnxN+PNxIO8/d276LFCKqBHMPY1xsF7RVGOZON/35I8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=GMud3xQq; 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="GMud3xQq" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2AE2A1F00A3E; Fri, 21 Aug 2026 16:41:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1787330511; bh=34Su/I9rz3BnICZOrzMkpZ5mtIBm7aPDtUnt6JfY/Rs=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=GMud3xQq+L+cnRIFXzW1KK7vR8GGpFHzhvsg9UKHx/hUQDNNI4W7qHFL+MEigbxsf L7/7XBt1HJb+ZOPcQ8i7hP74H9BcY1FQsHAPLqO8UcNjAsK6noUdeKr7uAXjkzGrxg AnUdtuggETdjutxQujo820lC6eIgdJDIfxke4Ly3NayUU25ver6udtvct01Srwcb5Z QHbBeOBG3/Pz+VxsS72VAAyYBPFP7SKPanLrYiaoTd8eySEy4YlKem+O0Ic/jx5025 DtiOAnR57HdQQt9VVgdRNwzIOWLULbxcH3T3opfVnbyCXA57VsV9vbWQ7rX7P+ahLi VUTXpK/AGuGNw== Date: Fri, 21 Aug 2026 17:41:46 +0100 From: "Lorenzo Stoakes (ARM)" To: Zi Yan Cc: Ferran Duarri , Andrew Morton , David Hildenbrand , 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 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: On Thu, Aug 20, 2026 at 04:15:30PM -0400, Zi Yan wrote: > On Thu Aug 20, 2026 at 3:08 PM EDT, 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. > > > > 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 > > affected. Paired with transparent_hugepage=always every anonymous fault > > becomes eligible, and under memory pressure the faulting thread can > > stall in compaction. > > > > "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 > > 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. > > > > 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. > > > > Signed-off-by: Ferran Duarri > > --- > > 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< > > > +Johannes, since he said Meta heavily rely khugepaged to make good use > of THP, he might give more insight here. > > The patch adds additional kswapd/kcompactd work when a system fails to > allocate THP for non madvised THP-eligible memory regions. If the > system's CPU utilization is high, kswapd/kcompactd can take CPU > resrouces from others, right? Performance numbers are needed to justify > this change. This patch is completely ludicrious so not really worth considering beyond the moot discussion points. People have seen really significant issues when changing this setting, it's very sensitive, and distros can set as needed. :) But maybe there's an interesting discussion to be had? > > -- > Best Regards, > Yan, Zi > -- Cheers, Lorenzo