From: Joshua Hahn <joshua.hahnjy@gmail.com>
To: zhongjinji <zhongjinji@honor.com>
Cc: akpm@linux-foundation.org, david@redhat.com,
lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com,
vbabka@suse.cz, rppt@kernel.org, surenb@google.com,
mhocko@suse.com, jackmanb@google.com, hannes@cmpxchg.org,
ziy@nvidia.com, zhengqi.arch@bytedance.com,
shakeel.butt@linux.dev, axelrasmussen@google.com,
yuanchu@google.com, weixugc@google.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, liulu.liu@honor.com,
feng.han@honor.com
Subject: Re: [PATCH] mm/page_alloc: Consider PCP pages as part of pfmemalloc_reserve
Date: Tue, 21 Oct 2025 07:54:26 -0700 [thread overview]
Message-ID: <20251021145427.3580609-1-joshua.hahnjy@gmail.com> (raw)
In-Reply-To: <20251021095004.12157-1-zhongjinji@honor.com>
On Tue, 21 Oct 2025 17:50:04 +0800 zhongjinji <zhongjinji@honor.com> wrote:
Hello Zhongjinji, thank you for your patch!
> When free_pages becomes critically low, the kernel prevents other tasks
> from entering the slow path to ensure that reclaiming tasks can
> successfully allocate memory.
>
> This blocking is important to avoid memory contention with reclaiming
> tasks. However, in some cases it is unnecessary because the PCP list may
> already contain sufficient pages, as freed pages are first placed there
> and are not immediately visible to the buddy system.
Based on my limiting understanding of pcp free pages, I had a concern here
on whether this would really provide the desired effect. That is, the pages
in the pcp are not available to the buddy allocator unless we drain the pcp
lists (and this operation is not free), I was unsure if there was a clear
benefit to allowing the system to go unblocked.
If we are already at the point where we need the pcp pages to have enough
free pages to go over the watermark, perhaps it makes sense to just block
tasks for now, and enter direct reclaim? Allowing more allocations might
lead the system to be in a worse state than before, and will have to
go through direct reclaim anyways.
Please let me know if this makes sense!
> By accounting PCP pages as part of pfmemalloc_reserve, we can reduce
> unnecessary blocking and improve system responsiveness under low-memory
> conditions.
>
> Signed-off-by: zhongjinji <zhongjinji@honor.com>
[...snip...]
> +int zone_pcp_pages_count(struct zone *zone)
> +{
> + struct per_cpu_pages *pcp;
> + int total_pcp_pages = 0;
> + int cpu;
> +
> + for_each_online_cpu(cpu) {
> + pcp = per_cpu_ptr(zone->per_cpu_pageset, cpu);
> + total_pcp_pages += pcp->count;
Could this be racy? What is stopping the pcp count from decreasing while we
are iterating over each online cpu, over each managed zone? Under the
memory pressure conditions that this patch is aiming to fix, I think that
there is a good chance the numer we get here will be very outdated by the time
we try to take action based on it, and we may require the system to be
further stalled since we don't take action to reclaim memory.
[...snip...]
Please feel free to let me know if I am missing something obvious. Again,
I am not very familiar with the pcp code, so there is a good chance that
you are seeing something that I am not : -)
Thank you for the patch, I hope you have a great day!
Joshua
next prev parent reply other threads:[~2025-10-21 14:54 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-21 9:50 zhongjinji
2025-10-21 14:54 ` Joshua Hahn [this message]
2025-10-21 18:04 ` [PATCH] mm/page_alloc: Consider PCP pages as part of jinji zhong
2025-10-22 7:41 ` Vlastimil Babka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251021145427.3580609-1-joshua.hahnjy@gmail.com \
--to=joshua.hahnjy@gmail.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=axelrasmussen@google.com \
--cc=david@redhat.com \
--cc=feng.han@honor.com \
--cc=hannes@cmpxchg.org \
--cc=jackmanb@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=liulu.liu@honor.com \
--cc=lorenzo.stoakes@oracle.com \
--cc=mhocko@suse.com \
--cc=rppt@kernel.org \
--cc=shakeel.butt@linux.dev \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
--cc=weixugc@google.com \
--cc=yuanchu@google.com \
--cc=zhengqi.arch@bytedance.com \
--cc=zhongjinji@honor.com \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®