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 821C4330B11 for ; Mon, 25 May 2026 09:11:14 +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=1779700275; cv=none; b=Oah2VQrbCFEJw9FYKzcMDqXvKQOwWefNI9A8iY1cekITThP8GhiVg9SfFBI/ZVBaQSPGQntf7g3PIwiQGTs81hIDc1yPfYj53AqwF4RfRU1idSuoFRmf/IVLy7UauGJq8/k0J7UCgJ5azd8wDCIaWQSpOXo5eDw7JlvwWjtfqJI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779700275; c=relaxed/simple; bh=RCWfu6HllcDbyS7shbI3DdbjEGQjKvoaGPUyFLHyfTU=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=WK0YaSENHz1NqChaUL5o8Ctd2JwzPjsNeFT1QI4WzHUWYYclzvg6sExJGQnw+7sAciIzKmOKF2yQyOHqtoR0byghP0ZcEy7qjk+za2zfIzeB3aSXMS1+c6R2KWHlmGuZXpsN3JhqtJIJNhKU19bHxaN8Wf75pN/tJy17YTCJm7g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=A21LqXUs; 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="A21LqXUs" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D5CF41F000E9; Mon, 25 May 2026 09:11:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1779700274; bh=6/3YwuR3pOuMJcREwqo1Stxq68Iks4DEidfzj/cnmA8=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=A21LqXUsHs9WkANqSp30wt7TgFZJcNduejcxaYdnhFfU+b9SVhlTrU/pyVKqAEVl4 TmxIvojGO97H72XFqvUdVsHhsDSlPU0sBTjxGWAjpGysU7HD1SvKIV3MBn2gZD96DH U8w3WmXbZsmmu1FZ3wEpLq0VzLx41X2380+nq4sMvhaMr7i7VOL5JUcKmSPLMNHR1s rxmZOi9MKKnxbwe/U2pxOi15Ar1FHljSybjxQ90G1EHrbC5bHXIXz2VrdR1xGtd5oM vFu9bqMaCeMilEdvfpEgLBgHyxtCgiQfQnYR6+IXOHjpVn5tykgVsNBvB7gYGsEnrL 3Oo6LAhct1Sow== Message-ID: Date: Mon, 25 May 2026 11:11:10 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm/page_alloc: skip high atomic reservation at or below costly order Content-Language: en-US To: Johannes Weiner , "JP Kobryn (Meta)" Cc: akpm@linux-foundation.org, surenb@google.com, mhocko@suse.com, jackmanb@google.com, ziy@nvidia.com, linux-mm@kvack.org, usama.arif@linux.dev, kirill@shutemov.name, willy@infradead.org, linux-kernel@vger.kernel.org, kernel-team@meta.com References: <20260519012532.272770-1-jp.kobryn@linux.dev> From: "Vlastimil Babka (SUSE)" In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 5/19/26 22:28, Johannes Weiner wrote: > On Mon, May 18, 2026 at 06:25:32PM -0700, JP Kobryn (Meta) wrote: >> We're seeing a pattern in production where 2MB THP order-9 allocations are >> failing due to fragmentation and triggering reclaim on systems with plenty >> of free memory. Over time, the success rate of these THP allocations do not >> increase at all. >> >> Inspecting zone->vm_stat[NR_FREE_PAGES] via kprobe on compaction_suitable() >> indicated the given zone had sufficient free pages for order-9 allocations, >> yet they were going unused. Drilling down into the zone and inspecting >> /proc/pagetypeinfo revealed why. Order-9 blocks were accumulating in the >> zone's HighAtomic bucket (while zero were present in Movable). THP is >> unable to draw blocks from HighAtomic since that bucket is not in the >> fallback list. >> >> The heuristic for reserving pageblocks in HighAtomic is that any atomic >> allocation greater than order-0 will result in the full pageblock being >> captured. This means that an order-1 atomic allocation will over-reserve by >> 256x, a full 512 pageblock. >> >> Gate the reservation on order. Skip for allocations at or below >> PAGE_ALLOC_COSTLY_ORDER. This prevents smaller atomic allocations from >> reserving entire pageblocks, and significantly helps when THP is in use on >> a fragmented but otherwise healthy system. >> >> Testing was performed using an A/B instagram workload receiving prod >> traffic. Each side had ~60 hosts with 64G memory. The patch resulted in >> several gains: >> >> Unpatched >> HighAtomic pageblocks per host: 309-312 (1% of zone or 620MB), >> ...all order-9 blocks in HighAtomic >> THP success rate: 1-6% >> Compaction success rate: 0-2% >> pgscan_kswapd (total across ~60 hosts, per minute): ~70.2M >> Atomic order-4+ allocations: 0 >> >> Patched >> HighAtomic pageblocks per host: 1 >> THP success rate: 44-78% >> Compaction success rate: 24-47% >> pgscan_kswapd (total across ~60 hosts, per minute): ~29.9M >> Atomic order-4+ allocations: 0 > > This is an interesting patch. A couple of thoughts: > > 1. You disabled the highatomic reserve for this workload and it didn't > seem to matter. Presumably > 2. Maxing out the reserves is odd. ALLOC_HIGHATOMIC allocations will > try reserved space first, Hmm, but if the allocation succeeds before entering slowpath, ALLOC_NON_BLOCK won't be set. But reserving another block should mean we already exhausted the reserved ones. Unreserving is only done when direct reclaim made some progress but failed to produce a page. But if it works, or kswapd does the job, we won't enter it? > and I'd expect things that are commonly > highatomic to be short-lived. Why don't we stop with a couple of > claimed highatomic blocks that get continuously recycled? Maybe it's some big burst of highatomic allocations that leads to the reservations and then they stay around "forever"? If that's the case I think we should be perhaps looking at the unreserving being done more proactively, rather than limiting things to costly order. > 3. The impact on THP and compaction success rate is pretty > extreme. How can 1% of memory throw such a wrench into the gears? Maybe if ~all free memory is in the highatomic blocks, compaction can't be effective much. Or some suitability check somewhere in reclaim+compaction wrongly assumes the highatomic blocks are usable, so it won't do the work. > Have you tried this with other workloads?