From: "David Hildenbrand (Red Hat)" <david@kernel.org>
To: Gregory Price <gourry@gourry.net>, Michal Hocko <mhocko@suse.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Aboorva Devarajan <aboorvad@linux.ibm.com>,
vbabka@suse.cz, surenb@google.com, jackmanb@google.com,
hannes@cmpxchg.org, ziy@nvidia.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, Oscar Salvador <OSalvador@suse.com>
Subject: Re: [PATCH] mm/page_alloc: make percpu_pagelist_high_fraction reads lock-free
Date: Wed, 3 Dec 2025 10:15:04 +0100 [thread overview]
Message-ID: <8b89bb59-6b6a-4a79-a571-e97b9ae5287f@kernel.org> (raw)
In-Reply-To: <aS_8BgwR3R_geayy@gourry-fedora-PF4VCD3F>
On 12/3/25 09:59, Gregory Price wrote:
> On Wed, Dec 03, 2025 at 09:42:59AM +0100, Michal Hocko wrote:
>> On Wed 03-12-25 03:35:51, Gregory Price wrote:
>>> if (!ret) {
>>> /*
>>> * TODO: fatal migration failures should bail
>>> * out
>>> */
>>> do_migrate_range(pfn, end_pfn);
>>> }
>>>
>>> Maybe it's time to implement the bail out?
>>
>> That would be great but can we tell transient from permanent migration
>> failures? Maybe long term pins could be treated as permanent failure.
>>
>
> I see deep in migration code `migrate_pages_batch()` we would return
> "Some other failure" as fatal:
>
> switch(rc) {
> case -ENOMEM:
> ...
> /* Note: some long-term pin handing is done here */
> break;
> case -EAGAIN:
> ...
> break;
> case 0:
> ...
> list_move_tail(&folio->lru, &unmap_folios);
> list_add_tail(&dst->lru, &dst_folios);
> break;
> default:
> /*
> * Permanent failure (-EBUSY, etc.):
> * unlike -EAGAIN case, the failed folio is
> * removed from migration folio list and not
> * retried in the next outer loop.
> */
> nr_failed++;
> stats->nr_thp_failed += is_thp;
> stats->nr_failed_pages += nr_pages;
> break;
> }
>
> So at a minimum we could at least check for !(ENOMEM,EAGAIN) I suppose?
>
> It's unclear to me based on this code here how longerm pinning would
> return. Maybe David knows.
I would assume that additional references will always result in -EAGAIN.
Remember that we cannot distinguish short-term pins from long-term pins.
We should never have longterm-pins on ZONE_MOVABLE, unless something
broke that contract and needs to be fixed.
--
Cheers
David
next prev parent reply other threads:[~2025-12-03 9:15 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-01 6:00 [PATCH] mm/page_alloc: make percpu_pagelist_high_fraction reads lock-free Aboorva Devarajan
2025-12-01 17:41 ` Andrew Morton
2025-12-03 8:27 ` Michal Hocko
2025-12-03 8:35 ` Gregory Price
2025-12-03 8:42 ` Michal Hocko
2025-12-03 8:51 ` David Hildenbrand (Red Hat)
2025-12-03 9:02 ` Gregory Price
2025-12-03 9:08 ` David Hildenbrand (Red Hat)
2025-12-03 9:23 ` Gregory Price
2025-12-03 9:26 ` Gregory Price
2025-12-03 11:28 ` David Hildenbrand (Red Hat)
2025-12-03 8:59 ` Gregory Price
2025-12-03 9:15 ` David Hildenbrand (Red Hat) [this message]
2025-12-03 9:42 ` Michal Hocko
2025-12-03 11:22 ` David Hildenbrand (Red Hat)
2025-12-08 17:30 ` Aboorva Devarajan
2025-12-08 18:15 ` Michal Hocko
2025-12-08 19:29 ` David Hildenbrand (Red Hat)
2025-12-03 8:21 ` Michal Hocko
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=8b89bb59-6b6a-4a79-a571-e97b9ae5287f@kernel.org \
--to=david@kernel.org \
--cc=OSalvador@suse.com \
--cc=aboorvad@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=gourry@gourry.net \
--cc=hannes@cmpxchg.org \
--cc=jackmanb@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=surenb@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.