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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <877bwyxvvl.fsf@linux.dev>
Date: Mon, 13 Oct 2025 15:46:54 -0700
From: Roman Gushchin <roman.gushchin@...ux.dev>
To: Vlastimil Babka <vbabka@...e.cz>
Cc: Barry Song <21cnbao@...il.com>,  netdev@...r.kernel.org,
  linux-mm@...ck.org,  linux-doc@...r.kernel.org,
  linux-kernel@...r.kernel.org,  Barry Song <v-songbaohua@...o.com>,
  Jonathan Corbet <corbet@....net>,  Eric Dumazet <edumazet@...gle.com>,
  Kuniyuki Iwashima <kuniyu@...gle.com>,  Paolo Abeni <pabeni@...hat.com>,
  Willem de Bruijn <willemb@...gle.com>,  "David S. Miller"
 <davem@...emloft.net>,  Jakub Kicinski <kuba@...nel.org>,  Simon Horman
 <horms@...nel.org>,  Suren Baghdasaryan <surenb@...gle.com>,  Michal Hocko
 <mhocko@...e.com>,  Brendan Jackman <jackmanb@...gle.com>,  Johannes
 Weiner <hannes@...xchg.org>,  Zi Yan <ziy@...dia.com>,  Yunsheng Lin
 <linyunsheng@...wei.com>,  Huacai Zhou <zhouhuacai@...o.com>,  Alexei
 Starovoitov <alexei.starovoitov@...il.com>,  Harry Yoo
 <harry.yoo@...cle.com>,  David Hildenbrand <david@...hat.com>,  Matthew
 Wilcox <willy@...radead.org>
Subject: Re: [RFC PATCH] mm: net: disable kswapd for high-order network
 buffer allocation

Vlastimil Babka <vbabka@...e.cz> writes:

> On 10/13/25 12:16, Barry Song wrote:
>> From: Barry Song <v-songbaohua@...o.com>
>> 
>> On phones, we have observed significant phone heating when running apps
>> with high network bandwidth. This is caused by the network stack frequently
>> waking kswapd for order-3 allocations. As a result, memory reclamation becomes
>> constantly active, even though plenty of memory is still available for network
>> allocations which can fall back to order-0.
>> 
>> Commit ce27ec60648d ("net: add high_order_alloc_disable sysctl/static key")
>> introduced high_order_alloc_disable for the transmit (TX) path
>> (skb_page_frag_refill()) to mitigate some memory reclamation issues,
>> allowing the TX path to fall back to order-0 immediately, while leaving the
>> receive (RX) path (__page_frag_cache_refill()) unaffected. Users are
>> generally unaware of the sysctl and cannot easily adjust it for specific use
>> cases. Enabling high_order_alloc_disable also completely disables the
>> benefit of order-3 allocations. Additionally, the sysctl does not apply to the
>> RX path.
>> 
>> An alternative approach is to disable kswapd for these frequent
>> allocations and provide best-effort order-3 service for both TX and RX paths,
>> while removing the sysctl entirely.

I'm not sure this is the right path long-term. There are significant
benefits associated with using larger pages, so making the kernel fall
back to order-0 pages easier and sooner feels wrong, tbh. Without kswapd
trying to defragment memory, the only other option is to force tasks
into the direct compaction and it's known to be problematic.

I wonder if instead we should look into optimizing kswapd to be less
power-hungry?

And if you still prefer to disable kswapd for this purpose, at least it
should be conditional to vm.laptop_mode. But again, I don't think it's
the right long-term approach.

Thanks!