From: Michal Hocko <mhocko@suse.com>
To: mawupeng <mawupeng1@huawei.com>
Cc: ying.huang@intel.com, akpm@linux-foundation.org,
mgorman@techsingularity.net, dmaluka@chromium.org,
liushixin2@huawei.com, wangkefeng.wang@huawei.com,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm, proc: collect percpu free pages into the free pages
Date: Tue, 10 Sep 2024 15:11:48 +0200 [thread overview]
Message-ID: <ZuBFlMgyqfXEph2g@tiehlicka> (raw)
In-Reply-To: <26e53efe-7a54-499a-8d3f-345d29d90348@huawei.com>
On Tue 10-09-24 20:11:36, mawupeng wrote:
>
>
> On 2024/9/4 15:28, Michal Hocko wrote:
> > On Wed 04-09-24 14:49:20, mawupeng wrote:
[...]
> >> Current the problem is amount the pcp, which can increase to 4.6%(24644M)
> >> of the total 512G memory.
> >
> > Why is that a problem?
>
> MemAvailable
> An estimate of how much memory is available for starting new
> applications, without swapping. Calculated from MemFree,
> SReclaimable, the size of the file LRU lists, and the low
> watermarks in each zone.
>
> The PCP memory is essentially available memory and will be reclaimed before OOM.
> In essence, it is not fundamentally different from reclaiming file pages, as both
> are reclaimed within __alloc_pages_direct_reclaim.
It is not _fundamentally_ different but the reclaim trigger bar is
different (much higher). You might get into swapping while still keeping
pcp cache available for example.
MemAvailable has been an estimate. Time has proven not a great one as
it is hard to set expectations around that. You are focusing on pcp
caches but there others that might are not covered (e.g. networking
stack can do a lot of caching on its own). MemAvailable will never be
perfect and if you are hitting limits of its usefulness I would
recommend finding a different way to achieve your goals (which are still
not really clear to me TBH).
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2024-09-10 13:11 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-30 1:44 Wupeng Ma
2024-08-30 7:53 ` Huang, Ying
2024-09-02 1:11 ` mawupeng
2024-09-02 1:29 ` Huang, Ying
2024-09-03 1:50 ` mawupeng
2024-09-03 8:09 ` Michal Hocko
2024-09-04 6:49 ` mawupeng
2024-09-04 7:28 ` Michal Hocko
2024-09-10 12:11 ` mawupeng
2024-09-10 13:11 ` Michal Hocko [this message]
2024-09-11 5:37 ` Huang, Ying
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=ZuBFlMgyqfXEph2g@tiehlicka \
--to=mhocko@suse.com \
--cc=akpm@linux-foundation.org \
--cc=dmaluka@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=liushixin2@huawei.com \
--cc=mawupeng1@huawei.com \
--cc=mgorman@techsingularity.net \
--cc=wangkefeng.wang@huawei.com \
--cc=ying.huang@intel.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