[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ZWRYZmulV0B-Jv3k@tiehlicka>
Date: Mon, 27 Nov 2023 09:50:46 +0100
From: Michal Hocko <mhocko@...e.com>
To: Dmytro Maluka <dmaluka@...omium.org>
Cc: Liu Shixin <liushixin2@...wei.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
huang ying <huang.ying.caritas@...il.com>,
Aaron Lu <aaron.lu@...el.com>,
Dave Hansen <dave.hansen@...el.com>,
Jesper Dangaard Brouer <brouer@...hat.com>,
Vlastimil Babka <vbabka@...e.cz>,
Kemi Wang <kemi.wang@...el.com>,
Kefeng Wang <wangkefeng.wang@...wei.com>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH -next v2] mm, proc: collect percpu free pages into the
free pages
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
Powered by blists - more mailing lists