From: Kiryl Shutsemau <kirill@shutemov.name>
To: Johannes Weiner <hannes@cmpxchg.org>
Cc: Harry Yoo <harry@kernel.org>, Vlastimil Babka <vbabka@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
Brendan Jackman <brendan.jackman@linux.dev>,
Zi Yan <ziy@nvidia.com>, Shakeel Butt <shakeel.butt@linux.dev>,
Usama Arif <usama.arif@linux.dev>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org, kernel-team@meta.com
Subject: Re: [PATCH] mm: page_alloc: make defrag_mode retries follow the promoted order
Date: Tue, 6 Oct 2026 10:13:46 +0100 [thread overview]
Message-ID: <asS6uQPZY_9r2uUG@thinkstation> (raw)
In-Reply-To: <20261006081050.GA234057@cmpxchg.org>
On Tue, Oct 06, 2026 at 10:10:50AM +0200, Johannes Weiner wrote:
> Without counter indication, I would prefer to keep the tighter
> guarantees. ISTR this mattered on some of my ext4 tests in the past
> with the buffer locking.
OK, v2 takes the priority floor and the COMPACT_SUCCESS retry limit
from the requested order, with the explicit promoted order folded in.
> > Should defrag_mode treat MIGRATE_MOVABLE like ZONE_MOVABLE there and
> > move the page out at pin time? Ideally we might want to move it back
> > on unpin, but it can be done by compaction too.
>
> Should it even be specific to defrag_mode? I suppose without it, the
> poisoning from fallbacks would dominate by a landslide under
> pressure. But these pins can mess with compactability long before
> becoming capacity-bound.
Agreed, a pinned page in a movable block hurts compaction regardless of
defrag_mode.
It can make longterm pinning more expensive, but it is the right place
to pay the cost.
--
Kiryl Shutsemau / Kirill A. Shutemov
next prev parent reply other threads:[~2026-10-06 9:13 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-29 17:45 [PATCH] mm: page_alloc: make defrag_mode retries follow the promoted order Kiryl Shutsemau
2026-09-29 18:39 ` Harry Yoo
2026-09-30 13:32 ` Kiryl Shutsemau
2026-09-30 14:06 ` Johannes Weiner
2026-10-02 9:59 ` Kiryl Shutsemau
2026-10-06 8:10 ` Johannes Weiner
2026-10-06 9:13 ` Kiryl Shutsemau [this message]
2026-09-29 19:58 ` Andrew Morton
2026-09-30 12:35 ` Kiryl Shutsemau
2026-09-30 20:02 ` Andrew Morton
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=asS6uQPZY_9r2uUG@thinkstation \
--to=kirill@shutemov.name \
--cc=akpm@linux-foundation.org \
--cc=brendan.jackman@linux.dev \
--cc=david@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=harry@kernel.org \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=shakeel.butt@linux.dev \
--cc=stable@vger.kernel.org \
--cc=surenb@google.com \
--cc=usama.arif@linux.dev \
--cc=vbabka@kernel.org \
--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.