linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.com>
To: Dmytro Maluka <dmaluka@chromium.org>
Cc: Liu Shixin <liushixin2@huawei.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	huang ying <huang.ying.caritas@gmail.com>,
	Aaron Lu <aaron.lu@intel.com>,
	Dave Hansen <dave.hansen@intel.com>,
	Jesper Dangaard Brouer <brouer@redhat.com>,
	Vlastimil Babka <vbabka@suse.cz>, Kemi Wang <kemi.wang@intel.com>,
	Kefeng Wang <wangkefeng.wang@huawei.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH -next v2] mm, proc: collect percpu free pages into the free pages
Date: Mon, 27 Nov 2023 09:50:46 +0100	[thread overview]
Message-ID: <ZWRYZmulV0B-Jv3k@tiehlicka> (raw)
In-Reply-To: <ZWDjbrHx6XNzAtl_@google.com>

On Fri 24-11-23 18:54:54, Dmytro Maluka wrote:
[...]
> But looking at the code in __alloc_pages() and around, I see you are
> right: we don't try draining other CPUs' PCP lists *before* resorting to
> direct reclaim, compaction etc.
> 
> BTW, why not? Shouldn't draining PCP lists be cheaper than pageout() in
> any case?

My guess would be that draining remote pcp caches is quite expensive on
its own. This requires IPIs, preempting whatever is running there and
wait for the all the cpus with pcp caches to be done. On the other hand
reclaiming a mostly clean page cache could be much less expensive. 

Also consider that refilling those pcp caches is not free either (you
might hit zone lock contetion and who knows what else).

Last but not least also consider that many systems could be just on the
edge of low/min watermark with a lot of cached data. If we drained all
pcp caches whenever we reclaim this could just make the cache pointless.

All that being said, I do not remember any actual numbers or research
about this.
-- 
Michal Hocko
SUSE Labs


      parent reply	other threads:[~2023-11-27  8:50 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-22  2:33 [PATCH -next] " Liu Shixin
2022-08-22  3:33 ` [PATCH -next v2] " Liu Shixin
2022-08-22 21:12   ` Andrew Morton
2022-08-22 21:13     ` Andrew Morton
2022-08-23 13:12       ` Liu Shixin
2022-08-23  7:50     ` Michal Hocko
2022-08-23 12:46       ` Liu Shixin
2022-08-23 13:37         ` Michal Hocko
2022-08-24 10:05           ` Liu Shixin
2022-08-24 10:12             ` Michal Hocko
2023-11-24 17:54           ` Dmytro Maluka
2023-11-25  2:22             ` Kefeng Wang
2023-11-27  8:50             ` Michal Hocko [this message]

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=ZWRYZmulV0B-Jv3k@tiehlicka \
    --to=mhocko@suse.com \
    --cc=aaron.lu@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=brouer@redhat.com \
    --cc=dave.hansen@intel.com \
    --cc=dmaluka@chromium.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=huang.ying.caritas@gmail.com \
    --cc=kemi.wang@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=liushixin2@huawei.com \
    --cc=vbabka@suse.cz \
    --cc=wangkefeng.wang@huawei.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