Re: [RFC PATCH] mm: net: disable kswapd for high-order network buffer allocation

On Tue 14-10-25 10:22:03, Shakeel Butt wrote:

On Tue, Oct 14, 2025 at 05:14:47PM +0200, Michal Hocko wrote:

quoted

On Tue 14-10-25 07:27:06, Shakeel Butt wrote:

quoted

On Tue, Oct 14, 2025 at 09:26:49AM +0200, Michal Hocko wrote:

quoted

On Mon 13-10-25 20:30:13, Vlastimil Babka wrote:

quoted

On 10/13/25 12:16, Barry Song wrote:

quoted

From: Barry Song <redacted>

[...]

quoted

I wonder if we should either:

1) sacrifice a new __GFP flag specifically for "!allow_spin" case to
determine it precisely.

As said in other reply I do not think this is a good fit for this
specific case as it is all or nothing approach. Soon enough we discover
that "no effort to reclaim/compact" hurts other usecases. So I do not
think we need a dedicated flag for this specific case. We need a way to
tell kswapd/kcompactd how much to try instead.

To me this new floag is to decouple two orthogonal requests i.e. no lock
semantic and don't wakeup kswapd. At the moment the lack of kswapd gfp
flag convey the semantics of no lock. This can lead to unintended usage
of no lock semantics by users which for whatever reason don't want to
wakeup kswapd.

I would argue that callers should have no business into saying whether
the MM should wake up kswapd or not. The flag name currently suggests
that but that is mostly for historic reasons. A random page allocator
user shouldn't really care about this low level detail, really.

I agree but unless we somehow enforce/warn for such cases, there will be
users doing this. A simple grep shows kmsan is doing this. I worry there
might be users who are manually setting up gfp flags for their
allocations and not providing kswapd flag explicitly. Finding such cases
with grep is not easy.

You are right but this is inherent problem of our gfp interface. It is
too late to have a defensive interface I am afraid.

-- 
Michal Hocko
SUSE Labs