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 9681436DA0D for ; Fri, 31 Jul 2026 12:41:01 +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=1785501662; cv=none; b=nW8tcVooIDekhFXiFVUdc3tramm5B1HYYASDBdck7nVVsBzoPzxBENrgTlwFxO4kwR5WET5mto5PSpAwpmKyDJIz4XNMi4YMIGOk8vmXkgrorQAEIMEkGvZJGBKr/WcoLYgm18VAggT6KokhU7Tbn+NJu89Bvj/qG833XwcD9II= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785501662; c=relaxed/simple; bh=2ScpaoJB9uaPNjiYUetnXgs1Ot95mcifMCFTQM7AF5Q=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=jGSTj3Wb08f2uHicEIQOHQMSrDD/W7XhZpNTHrTWlLOwC6qnOvZPnoTGEn8QxFv5QtVIYuCAgVjvfP7mnR3BTUKUDa3un60wLAUNMWGQ8NQNByLJZ/OBTnYRcVCD3LYyBIXR0cBaLkoPLn2PtCZ0VZljftW0IGAUGZAKywee2yw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=IM4AZFnV; 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="IM4AZFnV" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B90701F00A3A; Fri, 31 Jul 2026 12:40:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785501661; bh=TZPfhyB157sYFTxtHnA680hCbQsHrYYadtzGHcFgiAo=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=IM4AZFnV306rXJOM4LXDy2ZvXhstyAnjiYFpjDWxYqTug/LZLnqLnmky1778nlqiH wxIH/4wL+FQx3rOyvUAR/LEUSwxiJyciBfxhAPI87AAwLxuB4kQaeop440NYuq7skS zm+Ahpuea/3Bn+iQegcrpyRjwsODrO/y2KnnXvFpvjMkPAQALPoaiTZtAhe5C+1DU4 tRhq48w8QbueyUvxBTw1Dko0vqmy6psjlKoqU2O5PXKftImdgz7G/vYPhU2unue6GB R2Rufv/4TtkLhYPWpBh2UoTF++bPyDWCea35hFjU4Ai30lgz93wPT8PM9KmQRFtmeH zqNwLTJ/JymYg== Date: Fri, 31 Jul 2026 13:40:42 +0100 From: "Lorenzo Stoakes (ARM)" To: Juan Yescas Cc: "David Hildenbrand (Arm)" , Andrew Morton , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , open list , "open list:MEMORY MANAGEMENT - CORE" , android-mm@google.com, fvdl@google.com, tkjos@google.com, minchan@google.com, dskiba@google.com Subject: Re: [RFC PATCH 00/16] Page Alloc Hogger Message-ID: References: <20260723074854.1013941-1-jyescas@google.com> <97605949-82c5-49e0-84b6-b42e8078b55d@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-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Tue, Jul 28, 2026 at 05:36:03PM -0700, Juan Yescas wrote: > On Tue, Jul 28, 2026 at 12:29 PM David Hildenbrand (Arm) > wrote: > > > > On 7/23/26 09:47, Juan Yescas wrote: > > > This patch series introduces the Page Alloc Hogger. The Page Alloc Hogger > > > allows you to allocate memory pages from specific nodes, zones, migration > > > types, and orders directly via debugfs. This provides key benefits for > > > testing and debugging: > > > > Would it be feasible to carry this as an OOT debugging module? Would a lot of > > symbols be missing to achieve that? > > > > Thanks David for the comment. > > The only symbol that would be needed to have this module as OOT is > "migratetype_names". Hmm I could have sworn I replied to this :) Anyway, I don't think there's any need to export this. It's not like we're going to radically rename them, and you'd probably have to update your module anyway if we added a new migratetype. So this being wholly contained in a module with no core changes seems the best way? Cheers, Lorenzo > > However, although this module was originally designed to debug CMA > issues, it can be > easily used to debug issues in kswapd, direct reclaims, OOM killer, > etc. We could even > use this module to add kunit test cases. > > Let's take for example this case. We want to allocate Unmovable memory and check > that the allocation came from Movable, as per the buddy allocator > fallback mechanism. > How can we do that in user space? > > $ cat /proc/pagetypeinfo > Page block order: 9 > Pages per block: 512 > > Free pages count per migrate type at order 0 1 2 3 4 5 6 7 8 9 10 > Node 0, zone DMA, type Unmovable 0 0 0 0 0 0 0 0 0 0 0 > Node 0, zone DMA, type Movable 1 1 1 0 1 1 2 2 1 3 732 > Node 0, zone DMA, type Reclaimable 0 0 0 0 0 0 0 0 0 0 0 > Node 0, zone DMA, type HighAtomic 0 0 0 0 0 0 0 0 0 0 0 > Node 0, zone DMA, type CMA 0 0 0 0 0 0 0 0 0 1 7 > Node 0, zone DMA, type Isolate 0 0 0 0 0 0 0 0 0 0 0 > Node 0, zone Normal, type Unmovable 13 7 0 1 0 0 1 0 1 0 0 > Node 0, zone Normal, type Movable 1 1 1 1 1 1 1 0 1 1 1221 > Node 0, zone Normal, type Reclaimable 1 0 0 0 0 0 1 0 0 1 0 > Node 0, zone Normal, type HighAtomic 0 0 0 0 0 0 0 0 0 0 0 > Node 0, zone Normal, type CMA 0 0 0 0 0 0 0 0 0 1 7 > Node 0, zone Normal, type Isolate 0 0 0 0 0 0 0 0 0 0 0 > > // Allocate Unmovable memory (note that there are NO Unmovable pages, > so the allocation will fall back from Movable) > $ echo 1221 > /sys/kernel/debug/mm/node-0/zone-Normal/order-10/migrate-Unmovable/nr_pages_allocs > > $ cat /proc/pagetypeinfo > Page block order: 9 > Pages per block: 512 > > Free pages count per migrate type at order 0 1 2 > 3 4 5 6 7 8 9 10 > Node 0, zone DMA, type Unmovable 0 0 0 > 0 0 0 0 0 0 0 0 > Node 0, zone DMA, type Movable 1 1 1 > 0 1 1 2 2 1 3 701 > Node 0, zone DMA, type Reclaimable 0 0 0 > 0 0 0 0 0 0 0 0 > Node 0, zone DMA, type HighAtomic 0 0 0 > 0 0 0 0 0 0 0 0 > Node 0, zone DMA, type CMA 0 0 0 > 0 0 0 0 0 0 1 31 > Node 0, zone DMA, type Isolate 0 0 0 > 0 0 0 0 0 0 0 0 > Node 0, zone Normal, type Unmovable 1 0 0 > 1 1 1 1 1 1 0 0 > Node 0, zone Normal, type Movable 1 0 1 > 1 1 1 1 1 1 1 7 > Node 0, zone Normal, type Reclaimable 0 1 0 > 0 1 0 0 0 1 0 0 > Node 0, zone Normal, type HighAtomic 0 0 0 > 0 0 0 0 0 0 0 0 > Node 0, zone Normal, type CMA 0 0 0 > 0 0 0 0 0 0 1 7 > Node 0, zone Normal, type Isolate 0 0 0 > 0 0 0 0 0 0 0 0 > > Number of blocks type Unmovable Movable Reclaimable > HighAtomic CMA Isolate > Node 0, zone DMA 14 1458 0 > 0 64 0 > Node 0, zone Normal 2440 102 2 > 0 16 0 > > // Now we want to test that Reclaimable memory allocations fall back > from ZONE_DMA and Migrate Movable > > $ echo 600 > /sys/kernel/debug/mm/node-0/zone-Normal/order-10/migrate-Reclaimable/nr_pages_allocs > # cat /proc/pagetypeinfo > Page block order: 9 > Pages per block: 512 > > Free pages count per migrate type at order 0 1 2 > 3 4 5 6 7 8 9 10 > Node 0, zone DMA, type Unmovable 0 0 0 > 0 0 1 1 0 0 1 0 > Node 0, zone DMA, type Movable 1 1 1 > 0 1 1 2 2 1 3 99 > Node 0, zone DMA, type Reclaimable 1 0 0 > 1 0 0 1 0 1 1 0 > Node 0, zone DMA, type HighAtomic 0 0 0 > 0 0 0 0 0 0 0 0 > Node 0, zone DMA, type CMA 0 0 0 > 0 0 0 0 0 0 1 31 > Node 0, zone DMA, type Isolate 0 0 0 > 0 0 0 0 0 0 0 0 > Node 0, zone Normal, type Unmovable 1 0 0 > 1 1 1 1 1 1 0 0 > Node 0, zone Normal, type Movable 0 0 0 > 1 0 0 1 0 1 0 7 > Node 0, zone Normal, type Reclaimable 0 1 0 > 0 1 0 0 0 1 0 0 > Node 0, zone Normal, type HighAtomic 0 0 0 > 0 0 0 0 0 0 0 0 > Node 0, zone Normal, type CMA 0 0 0 > 0 0 0 0 0 0 1 7 > Node 0, zone Normal, type Isolate 0 0 0 > 0 0 0 0 0 0 0 0 > > Number of blocks type Unmovable Movable Reclaimable > HighAtomic CMA Isolate > Node 0, zone DMA 16 254 1202 > 0 64 0 > Node 0, zone Normal 2440 102 2 > 0 16 0 > > // Now, we want to free all the MIGRATE_UNMOVABLE allocations and > sleep 1 second for every > // allocation and see how the pages return to the MIGRATE_UNMOVABLE bucket: > > for i in `seq 1 1221`; do echo $i > /sys/kernel/debug/mm/free; sleep 10; done > > // in another console > > watch cat /proc/pagetypeinfo > 2026-07-29 00:28:49 > > Page block order: 9 > Pages per block: 512 > > Free pages count per migrate type at order 0 1 2 > 3 4 5 6 7 8 9 10 > Node 0, zone DMA, type Unmovable 0 0 0 > 0 0 1 1 0 0 1 0 > Node 0, zone DMA, type Movable 1 1 1 > 0 1 1 2 2 1 3 99 > Node 0, zone DMA, type Reclaimable 1 0 0 > 1 0 0 1 0 1 1 0 > Node 0, zone DMA, type HighAtomic 0 0 0 > 0 0 0 0 0 0 0 0 > Node 0, zone DMA, type CMA 0 0 0 > 0 0 0 0 0 0 1 31 > Node 0, zone DMA, type Isolate 0 0 0 > 0 0 0 0 0 0 0 0 > Node 0, zone Normal, type Unmovable 1 0 0 > 1 1 1 1 1 1 0 698 > Node 0, zone Normal, type Movable 1 0 0 > 1 0 0 0 0 1 0 7 > Node 0, zone Normal, type Reclaimable 0 1 0 > 0 1 0 0 0 1 0 0 > Node 0, zone Normal, type HighAtomic 0 0 0 > 0 0 0 0 0 0 0 0 > Node 0, zone Normal, type CMA 0 0 0 > 0 0 0 0 0 0 1 7 > Node 0, zone Normal, type Isolate 0 0 0 > 0 0 0 0 0 0 0 0 > > Number of blocks type Unmovable Movable Reclaimable > HighAtomic CMA Isolate > Node 0, zone DMA 16 254 1202 > 0 64 0 > Node 0, zone Normal 2440 102 2 > 0 16 0 > > Achieving the same result in a user program is not as straightforward. > > The Page Alloc Hogger gives us the flexibility to allocate from any > valid memory we desire. > > As I mentioned before, it allows us to test/check/analyze/generate: > > - kwapd triggers > - direct reclaims > - OOM killer > - generate page fragmentation using simple scripts instead of complex programs > > Greetigns > > Juan > > > > -- > > Cheers, > > > > David -- Cheers, Lorenzo