From: Florian Westphal <fw@strlen.de>
To: Daniil Tatianin <d-tatianin@yandex-team.ru>
Cc: Eric Dumazet <edumazet@google.com>,
Pablo Neira Ayuso <pablo@netfilter.org>,
Jozsef Kadlecsik <kadlec@netfilter.org>,
Phil Sutter <phil@nwl.cc>,
"David S. Miller" <davem@davemloft.net>,
David Ahern <dsahern@kernel.org>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
netfilter-devel@vger.kernel.org, coreteam@netfilter.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH 1/3] netfilter/x_tables: go back to using vmalloc for xt_table_info
Date: Tue, 23 Sep 2025 13:36:57 +0200 [thread overview]
Message-ID: <aNKGWZSxY9RC0VWS@strlen.de> (raw)
In-Reply-To: <5f1ff52a-d2c2-40de-b00c-661b75c18dc7@yandex-team.ru>
Daniil Tatianin <d-tatianin@yandex-team.ru> wrote:
> > On Mon, Sep 22, 2025 at 12:48 PM Daniil Tatianin
> > <d-tatianin@yandex-team.ru> wrote:
> >> This code previously always used vmalloc for anything above
> >> PAGE_ALLOC_COSTLY_ORDER, but this logic was changed in
> >> commit eacd86ca3b036 ("net/netfilter/x_tables.c: use kvmalloc() in xt_alloc_table_info()").
> >>
> >> The commit that changed it did so because "xt_alloc_table_info()
> >> basically opencodes kvmalloc()", which is not actually what it was
> >> doing. kvmalloc() does not attempt to go directly to vmalloc if the
> >> order the caller is trying to allocate is "expensive", instead it only
> >> uses vmalloc as a fallback in case the buddy allocator is not able to
> >> fullfill the request.
> >>
> >> The difference between the two is actually huge in case the system is
> >> under memory pressure and has no free pages of a large order. Before the
> >> change to kvmalloc we wouldn't even try going to the buddy allocator for
> >> large orders, but now we would force it to try to find a page of the
> >> required order by waking up kswapd/kcompactd and dropping reclaimable memory
> >> for no reason at all to satisfy our huge order allocation that could easily
> >> exist within vmalloc'ed memory instead.
> > This would hint at an issue with kvmalloc(), why not fixing it, instead
> > of trying to fix all its users ?
I agree with Eric. There is nothing special in xtables compared to
kvmalloc usage elsewhere in the stack. Why "fix" xtables and not e.g.
rhashtable?
Please work with mm hackers to improve the situation for your use case.
Maybe its enough to raise __GFP_NORETRY in kmalloc_gfp_adjust() if size
results in >= PAGE_ALLOC_COSTLY_ORDER allocation.
> Thanks for the quick reply! From my understanding, there is a lot of
> callers of kvmalloc
> who do indeed benefit from the physical memory being contiguous, because
> it is then
> used for hardware DMA etc., so I'm not sure that would be feasible.
How can that work? kvmalloc won't make vmalloc backed memory
physically contiguous.
next prev parent reply other threads:[~2025-09-23 11:37 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-22 19:48 [PATCH 0/3] netfilter/x_tables: go back to using vmalloc Daniil Tatianin
2025-09-22 19:48 ` [PATCH 1/3] netfilter/x_tables: go back to using vmalloc for xt_table_info Daniil Tatianin
2025-09-22 21:12 ` Eric Dumazet
2025-09-23 10:11 ` Daniil Tatianin
2025-09-23 11:36 ` Florian Westphal [this message]
2025-09-23 12:04 ` Daniil Tatianin
2025-09-23 12:22 ` Eric Dumazet
2025-09-22 19:48 ` [PATCH 2/3] netfilter/x_tables: introduce a helper for freeing entry offsets Daniil Tatianin
2025-09-22 19:48 ` [PATCH 3/3] netfilter/x_tables: allocate entry_offsets with vcalloc Daniil Tatianin
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=aNKGWZSxY9RC0VWS@strlen.de \
--to=fw@strlen.de \
--cc=coreteam@netfilter.org \
--cc=d-tatianin@yandex-team.ru \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kadlec@netfilter.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pablo@netfilter.org \
--cc=phil@nwl.cc \
/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.