[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <38964e68-ac20-4595-b41d-8adc83ae6ba0@huawei.com>
Date: Wed, 9 Apr 2025 16:02:39 +0800
From: Yunsheng Lin <linyunsheng@...wei.com>
To: Johannes Weiner <hannes@...xchg.org>, Andrew Morton
<akpm@...ux-foundation.org>
CC: Vlastimil Babka <vbabka@...e.cz>, Brendan Jackman <jackmanb@...gle.com>,
Mel Gorman <mgorman@...hsingularity.net>, Carlos Song <carlos.song@....com>,
<linux-mm@...ck.org>, <linux-kernel@...r.kernel.org>, kernel test robot
<oliver.sang@...el.com>, <stable@...r.kernel.org>
Subject: Re: [PATCH 1/2] mm: page_alloc: speed up fallbacks in rmqueue_bulk()
On 2025/4/8 2:01, Johannes Weiner wrote:
...
>
> @@ -2934,6 +2981,7 @@ struct page *rmqueue_buddy(struct zone *preferred_zone, struct zone *zone,
> {
> struct page *page;
> unsigned long flags;
> + enum rmqueue_mode rmqm = RMQUEUE_NORMAL;
>
> do {
> page = NULL;
> @@ -2945,7 +2993,7 @@ struct page *rmqueue_buddy(struct zone *preferred_zone, struct zone *zone,
> if (alloc_flags & ALLOC_HIGHATOMIC)
> page = __rmqueue_smallest(zone, order, MIGRATE_HIGHATOMIC);
> if (!page) {
> - page = __rmqueue(zone, order, migratetype, alloc_flags);
> + page = __rmqueue(zone, order, migratetype, alloc_flags, &rmqm);
>
> /*
> * If the allocation fails, allow OOM handling and
It was not in the diff, but it seems the zone->lock is held inside the do..while loop,
doesn't it mean that the freelists are subject to outside changes and rmqm is stale?
Powered by blists - more mailing lists