From: "Christoph Lameter (Ampere)" <cl@linux.com>
To: Eric Dumazet <edumazet@google.com>
Cc: Shijie Huang <shijie@amperemail.onmicrosoft.com>,
Huang Shijie <shijie@os.amperecomputing.com>,
kuba@kernel.org, patches@amperecomputing.com,
davem@davemloft.net, horms@kernel.org, ast@kernel.org,
dhowells@redhat.com, linyunsheng@huawei.com,
aleksander.lobakin@intel.com, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org
Subject: Re: [PATCH v2] net: skbuff: set FLAG_SKB_NO_MERGE for skbuff_fclone_cache
Date: Thu, 29 Feb 2024 09:57:43 -0800 (PST) [thread overview]
Message-ID: <1e72ab23-8161-091e-dc9e-9ecfe84a02df@linux.com> (raw)
In-Reply-To: <CANn89iJpZ6udACMC9EF=zgYJU5rqLFiTuYJRf1UNA3UKu7CxJg@mail.gmail.com>
On Thu, 29 Feb 2024, Eric Dumazet wrote:
>> If you do not specify a node or GFP_THISNODE then the slub allocator will
>> opportunistically allocate sporadically from other nodes to avoid
>> fragmentation of slabs. The page allocator also will sporadically go off
>> node in order to avoid reclaim. The page allocator may go off node
>> extensively if there is a imbalance of allocation between node. The page
>> allocator has knobs to tune off node vs reclaim options. Doing more
>> reclaim will slow things down but give you local data.
>
> Maybe, maybe not.
>
> Going back to CONFIG_SLAB=y removes all mismatches, without having to
> use GFP_THISNODE at all,
> on hosts with plenty of available memory on all nodes.
Slab uses GFPTHISNODE by default and does not respect the memory policies
etc set for pages. As such it will causes additional overhead through
reclaim passses etc and memory policies will not be applied on a per page
level (as specd) but in its own layer on a per object basis. It causes
additional fragmentation.
> I think that is some kind of evidence that something is broken in SLUB land.
That is one of the reasons that SLAB was removed.
Slub defragmentation can be disabled by either GFP_THISNODE or tuning the
remote_claim knob in /sys/kernel/slab/<slabname>
next prev parent reply other threads:[~2024-02-29 17:57 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-20 2:18 [PATCH] net: skbuff: allocate the fclone in the current NUMA node Huang Shijie
2024-02-20 5:32 ` Eric Dumazet
2024-02-20 6:26 ` Shijie Huang
2024-02-20 8:17 ` Eric Dumazet
2024-02-20 8:37 ` Shijie Huang
2024-02-24 19:07 ` Eric Dumazet
2024-02-26 10:18 ` Jesper Dangaard Brouer
2024-02-26 10:29 ` Eric Dumazet
2024-02-27 6:28 ` [PATCH v2] net: skbuff: set FLAG_SKB_NO_MERGE for skbuff_fclone_cache Huang Shijie
2024-02-27 12:55 ` Eric Dumazet
2024-02-27 13:15 ` Eric Dumazet
2024-02-28 7:05 ` Shijie Huang
2024-02-28 9:38 ` Eric Dumazet
2024-02-29 17:00 ` Christoph Lameter (Ampere)
2024-02-29 17:07 ` Eric Dumazet
2024-02-29 17:57 ` Christoph Lameter (Ampere) [this message]
2024-02-29 16:56 ` Christoph Lameter (Ampere)
2024-02-26 10:10 ` [PATCH] net: skbuff: allocate the fclone in the current NUMA node Alexander Lobakin
2024-02-27 6:30 ` Shijie Huang
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=1e72ab23-8161-091e-dc9e-9ecfe84a02df@linux.com \
--to=cl@linux.com \
--cc=aleksander.lobakin@intel.com \
--cc=ast@kernel.org \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linyunsheng@huawei.com \
--cc=netdev@vger.kernel.org \
--cc=patches@amperecomputing.com \
--cc=shijie@amperemail.onmicrosoft.com \
--cc=shijie@os.amperecomputing.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;
as well as URLs for NNTP newsgroup(s).