From: Michal Hocko <mhocko@suse.com>
To: Shakeel Butt <shakeel.butt@linux.dev>
Cc: Vlastimil Babka <vbabka@suse.cz>, Barry Song <21cnbao@gmail.com>,
netdev@vger.kernel.org, linux-mm@kvack.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
Barry Song <v-songbaohua@oppo.com>,
Jonathan Corbet <corbet@lwn.net>,
Eric Dumazet <edumazet@google.com>,
Kuniyuki Iwashima <kuniyu@google.com>,
Paolo Abeni <pabeni@redhat.com>,
Willem de Bruijn <willemb@google.com>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, Simon Horman <horms@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Brendan Jackman <jackmanb@google.com>,
Johannes Weiner <hannes@cmpxchg.org>, Zi Yan <ziy@nvidia.com>,
Yunsheng Lin <linyunsheng@huawei.com>,
Huacai Zhou <zhouhuacai@oppo.com>,
Alexei Starovoitov <alexei.starovoitov@gmail.com>,
Harry Yoo <harry.yoo@oracle.com>,
David Hildenbrand <david@redhat.com>,
Matthew Wilcox <willy@infradead.org>,
Roman Gushchin <roman.gushchin@linux.dev>
Subject: Re: [RFC PATCH] mm: net: disable kswapd for high-order network buffer allocation
Date: Tue, 14 Oct 2025 17:14:47 +0200 [thread overview]
Message-ID: <aO5o548uQAuBcw0P@tiehlicka> (raw)
In-Reply-To: <qztimgoebp5ecdmvvgro6sdsng6r7t3pnddg7ddlxagaom73ge@a5wta5ym7enu>
On Tue 14-10-25 07:27:06, Shakeel Butt wrote:
> On Tue, Oct 14, 2025 at 09:26:49AM +0200, Michal Hocko wrote:
> > On Mon 13-10-25 20:30:13, Vlastimil Babka wrote:
> > > On 10/13/25 12:16, Barry Song wrote:
> > > > From: Barry Song <v-songbaohua@oppo.com>
> > [...]
> > > 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.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2025-10-14 15:14 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-13 10:16 Barry Song
2025-10-13 18:30 ` Vlastimil Babka
2025-10-13 21:35 ` Shakeel Butt
2025-10-13 21:53 ` Alexei Starovoitov
2025-10-13 22:25 ` Shakeel Butt
2025-10-13 22:46 ` Roman Gushchin
2025-10-14 4:31 ` Barry Song
2025-10-14 7:24 ` Michal Hocko
2025-10-14 7:26 ` Michal Hocko
2025-10-14 8:08 ` Barry Song
2025-10-14 14:27 ` Shakeel Butt
2025-10-14 15:14 ` Michal Hocko [this message]
2025-10-14 17:22 ` Shakeel Butt
2025-10-15 6:21 ` Michal Hocko
2025-10-15 18:26 ` Shakeel Butt
2025-10-13 18:53 ` Eric Dumazet
2025-10-14 3:58 ` Barry Song
2025-10-14 5:07 ` Eric Dumazet
2025-10-14 6:43 ` Barry Song
2025-10-14 7:01 ` Eric Dumazet
2025-10-14 8:17 ` Barry Song
2025-10-14 8:25 ` Eric Dumazet
2025-10-13 21:56 ` Matthew Wilcox
2025-10-14 4:09 ` Barry Song
2025-10-14 5:04 ` Eric Dumazet
2025-10-14 8:58 ` Barry Song
2025-10-14 9:49 ` Eric Dumazet
2025-10-14 10:19 ` Barry Song
2025-10-14 10:39 ` Eric Dumazet
2025-10-14 20:17 ` Barry Song
2025-10-15 6:39 ` Eric Dumazet
2025-10-15 7:35 ` Barry Song
2025-10-15 16:39 ` Suren Baghdasaryan
2025-10-14 14:37 ` Shakeel Butt
2025-10-14 20:28 ` Barry Song
2025-10-15 18:13 ` Shakeel Butt
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=aO5o548uQAuBcw0P@tiehlicka \
--to=mhocko@suse.com \
--cc=21cnbao@gmail.com \
--cc=alexei.starovoitov@gmail.com \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=david@redhat.com \
--cc=edumazet@google.com \
--cc=hannes@cmpxchg.org \
--cc=harry.yoo@oracle.com \
--cc=horms@kernel.org \
--cc=jackmanb@google.com \
--cc=kuba@kernel.org \
--cc=kuniyu@google.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linyunsheng@huawei.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=roman.gushchin@linux.dev \
--cc=shakeel.butt@linux.dev \
--cc=surenb@google.com \
--cc=v-songbaohua@oppo.com \
--cc=vbabka@suse.cz \
--cc=willemb@google.com \
--cc=willy@infradead.org \
--cc=zhouhuacai@oppo.com \
--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