[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20250819224111.e710eab683b7c7f941c7d1a7@linux-foundation.org>
Date: Tue, 19 Aug 2025 22:41:11 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Joshua Hahn <joshua.hahnjy@...il.com>
Cc: Johannes Weiner <hannes@...xchg.org>, Chris Mason <clm@...com>,
Vlastimil Babka <vbabka@...e.cz>, Suren Baghdasaryan <surenb@...le.com>,
Michal Hocko <mhocko@...e.com>, Brendan Jackman <jackmanb@...gle.com>, Zi
Yan <ziy@...dia.com>, linux-mm@...ck.org, linux-kernel@...r.kernel.org,
kernel-team@...a.com
Subject: Re: [PATCH] mm/page_alloc: Occasionally relinquish zone lock in
batch freeing
On Mon, 18 Aug 2025 11:58:03 -0700 Joshua Hahn <joshua.hahnjy@...il.com> wrote:
> While testing workloads with high sustained memory pressure on large machines
> (1TB memory, 316 CPUs), we saw an unexpectedly high number of softlockups.
> Further investigation showed that the lock in free_pcppages_bulk was being held
> for a long time, even being held while 2k+ pages were being freed.
It would be interesting to share some of those softlockup traces.
We have this CONFIG_PCP_BATCH_SCALE_MAX which appears to exist to
address precisely this issue. But only about half of the
free_pcppages_bulk() callers actually honor it.
So perhaps the fix is to fix the callers which forgot to implement this?
- decay_pcp_high() tried to implement CONFIG_PCP_BATCH_SCALE_MAX, but
that code hurts my brain.
- drain_pages_zone() implements it but, regrettably, doesn't use it
to periodically release pcp->lock. Room for improvement there.
Powered by blists - more mailing lists