From: Andrew Morton <akpm@linux-foundation.org>
To: Joshua Hahn <joshua.hahnjy@gmail.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>, Chris Mason <clm@fb.com>,
Vlastimil Babka <vbabka@suse.cz>,
Suren Baghdasaryan <surenb@gogle.com>,
Michal Hocko <mhocko@suse.com>,
Brendan Jackman <jackmanb@google.com>, Zi Yan <ziy@nvidia.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
kernel-team@meta.com
Subject: Re: [PATCH] mm/page_alloc: Occasionally relinquish zone lock in batch freeing
Date: Mon, 18 Aug 2025 17:13:40 -0700 [thread overview]
Message-ID: <20250818171340.2f4ce3356f1cda59acecab57@linux-foundation.org> (raw)
In-Reply-To: <20250818185804.21044-1-joshua.hahnjy@gmail.com>
On Mon, 18 Aug 2025 11:58:03 -0700 Joshua Hahn <joshua.hahnjy@gmail.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.
>
> Instead of holding the lock for the entirety of the freeing, check to see if
> the zone lock is contended every pcp->batch pages. If there is contention,
> relinquish the lock so that other processors have a change to grab the lock
> and perform critical work.
>
> In our fleet,
who is "our"?
> we have seen that performing batched lock freeing has led to
> significantly lower rates of softlockups, while incurring relatively small
> regressions (relative to the workload and relative to the variation).
>
> The following are a few synthetic benchmarks:
>
> Test 1: Small machine (30G RAM, 36 CPUs)
>
> ...
>
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
>
> ...
>
> @@ -1267,12 +1270,22 @@ static void free_pcppages_bulk(struct zone *zone, int count,
>
> /* must delete to avoid corrupting pcp list */
> list_del(&page->pcp_list);
> + batch -= nr_pages;
> count -= nr_pages;
> pcp->count -= nr_pages;
>
> __free_one_page(page, pfn, zone, order, mt, FPI_NONE);
> trace_mm_page_pcpu_drain(page, order, mt);
> - } while (count > 0 && !list_empty(list));
> + } while (batch > 0 && !list_empty(list));
> +
> + /*
> + * Prevent starving the lock for other users; every pcp->batch
> + * pages freed, relinquish the zone lock if it is contended.
> + */
> + if (count && spin_is_contended(&zone->lock)) {
> + spin_unlock_irqrestore(&zone->lock, flags);
> + spin_lock_irqsave(&zone->lock, flags);
> + }
> }
Pretty this isn't.
Sigh, we do so much stuff here and in __free_one_page().
What sort of guarantee do we have that the contending task will be able
to get in and grab the spinlock in that tiny time window?
next prev parent reply other threads:[~2025-08-19 0:13 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-18 18:58 [PATCH] mm/page_alloc: Occasionally relinquish zone lock in batch freeing Joshua Hahn
2025-08-19 0:13 ` Andrew Morton [this message]
2025-08-19 15:18 ` Joshua Hahn
2025-08-19 21:44 ` Andrew Morton
2025-08-20 13:20 ` Joshua Hahn
2025-08-19 9:15 ` Kiryl Shutsemau
2025-08-19 15:28 ` Joshua Hahn
2025-08-19 17:15 ` Shakeel Butt
2025-08-20 12:58 ` Kiryl Shutsemau
2025-08-19 15:34 ` Joshua Hahn
2025-08-20 1:29 ` Hillf Danton
2025-08-20 15:13 ` Joshua Hahn
2025-08-21 1:03 ` Hillf Danton
2025-08-20 5:41 ` Andrew Morton
2025-08-20 15:48 ` Joshua Hahn
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=20250818171340.2f4ce3356f1cda59acecab57@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=clm@fb.com \
--cc=hannes@cmpxchg.org \
--cc=jackmanb@google.com \
--cc=joshua.hahnjy@gmail.com \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=surenb@gogle.com \
--cc=vbabka@suse.cz \
--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;
as well as URLs for NNTP newsgroup(s).