From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-176.mta1.migadu.com (out-176.mta1.migadu.com [95.215.58.176]) (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 33486340A6B for ; Wed, 17 Jun 2026 17:36:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.176 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781717765; cv=none; b=XLuljecTQdvgI/gp88PieQV4Np4w2sZMYuQCtsf3Gu25BUFzKFfYAHv3pUt0W+cz61wHJe0IxjZSSDuALaIi6OFkPMiRMoYQKpIyscmDSXw3PakOgjEjFctD9aNMx47IcV1jpCnoXe2dGk05GX47PU9woPckOAvbelUcynSA21A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781717765; c=relaxed/simple; bh=lVS81dehuupgZSZOx1+p9TtUzHPaEMykPdLKWYn5QbY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=lhv8o7lFAZfd3c42rGPcYujz/DePRBKTy+eRqlix0VFu+aDoZhzoV+OoeU5HWfyjz+GjQXBb981TB5hskXzXphmMaX1j5FdE95m6alJHQRMXOT0IcQF9/uKzjE4nyGQTGsNUp6hyA00hVMxCBQ/O34eKF5f7V/pUEil0PtGa45A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=cLmyeicQ; arc=none smtp.client-ip=95.215.58.176 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="cLmyeicQ" Message-ID: <9370ec06-417c-46e1-8874-2613cdd6372b@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1781717761; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=T5V4tVp6yKnTKF6RniMiSm/7lWhPKZviX4QeBCL6yRU=; b=cLmyeicQb1OOCtrCPxsmlxji/GtE3X2lza/AN5O0w0VmbN+LeKTzSfzormpVJKwWIVhbQ1 sXjl7sqg5xTfjMp3mEa//bgFiluJtHsbg5c5PCEdP0g7OjWOB0G/c+7y6eYXhvyeh17Ntv 9qrkJe/DJzq6+6UaJE4D5gFDmqKvBv0= Date: Wed, 17 Jun 2026 10:35:43 -0700 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH] mm/page_alloc: use existing highatomic reserves on the buddy fastpath To: "Vlastimil Babka (SUSE)" , akpm@linux-foundation.org, david@kernel.org, ljs@kernel.org, liam@infradead.org, rppt@kernel.org, surenb@google.com, mhocko@suse.com, jackmanb@google.com, hannes@cmpxchg.org, ziy@nvidia.com, fvdl@google.com, linux-mm@kvack.org Cc: shakeel.butt@linux.dev, usama.arif@linux.dev, linux-kernel@vger.kernel.org References: <20260616191420.52556-1-jp.kobryn@linux.dev> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: JP Kobryn In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT On 6/17/26 6:02 AM, Vlastimil Babka (SUSE) wrote: > On 6/16/26 21:14, JP Kobryn wrote: >> ALLOC_HIGHATOMIC currently provides both access to MIGRATE_HIGHATOMIC free >> pages and permission to create new highatomic pageblock reserves. This >> makes it unsuitable for the fastpath. >> >> However, the fastpath can reach rmqueue_buddy() while MIGRATE_HIGHATOMIC >> reserves have free pages available. In this situation, the allocation can >> fall back to other migratetypes without trying those reserves first. >> >> Allow high-priority non-blocking allocations above order-0 and up to the >> costly order to use existing MIGRATE_HIGHATOMIC reserves on the buddy >> fastpath without granting permission to grow these reserves. Add >> ALLOC_HIGHATOMIC_RESERVE for allocations that may both access >> MIGRATE_HIGHATOMIC and grow the reserves. Change the semantics of >> ALLOC_HIGHATOMIC so that it may only access the reserves. >> >> A UDP receive workload was run with free MIGRATE_HIGHATOMIC pageblocks >> available in the target zone. Before this patch, the workload did not >> consume these blocks. With this patch, comparable runs consumed available >> blocks for 96-100% of eligible order-1 atomic allocations reaching the >> buddy path, with no highatomic misses observed. The workload did not grow >> highatomic reserves and NAPI page-frag allocations remained healthy with no >> failures or order-0 fallbacks. > > Great. > >> Signed-off-by: JP Kobryn > > LGTM, I have just one style suggestion. If you agree and apply it, feel free > to add: > > Reviewed-by: Vlastimil Babka (SUSE) Thanks for the quick review. > > ... and (unless other reviews raise something) send v2 rebased to 7.2-rc1 > once it's released. Thanks! > >> --- >> mm/internal.h | 4 +++- >> mm/page_alloc.c | 34 +++++++++++++++++++++++++++------- >> 2 files changed, 30 insertions(+), 8 deletions(-) >> [...] > > And only here add both ALLOC_HIGHATOMIC and ALLOC_HIGHATOMIC_RESERVE. > I.e. ALLOC_HIGHATOMIC_RESERVE would not be a superset of ALLOC_HIGHATOMIC, > but access to reserves and ability to grow them would be decoupled. The > comments on the flags actually suggest that's the case. I like this idea and will decouple in v2.