From: Shijie Huang <shijie@amperemail.onmicrosoft.com>
To: Eric Dumazet <edumazet@google.com>,
Huang Shijie <shijie@os.amperecomputing.com>
Cc: 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, cl@os.amperecomputing.com
Subject: Re: [PATCH] net: skbuff: allocate the fclone in the current NUMA node
Date: Tue, 20 Feb 2024 14:26:01 +0800 [thread overview]
Message-ID: <bea860f8-a196-4dff-a655-4da920e2ebfa@amperemail.onmicrosoft.com> (raw)
In-Reply-To: <CANn89iJoHDzfYfhcwVvR4m7DiVG-UfFNqm+D1WD-2wjOttk6ew@mail.gmail.com>
在 2024/2/20 13:32, Eric Dumazet 写道:
> On Tue, Feb 20, 2024 at 3:18 AM Huang Shijie
> <shijie@os.amperecomputing.com> wrote:
>> The current code passes NUMA_NO_NODE to __alloc_skb(), we found
>> it may creates fclone SKB in remote NUMA node.
> This is intended (WAI)
Okay. thanks a lot.
It seems I should fix the issue in other code, not the networking.
>
> What about the NUMA policies of the current thread ?
We use "numactl -m 0" for memcached, the NUMA policy should allocate
fclone in
node 0, but we can see many fclones were allocated in node 1.
We have enough memory to allocate these fclones in node 0.
>
> Has NUMA_NO_NODE behavior changed recently?
I guess not.
>
> What means : "it may creates" ? Please be more specific.
When we use the memcached for testing in NUMA, there are maybe 20% ~ 30%
fclones were allocated in
remote NUMA node.
After this patch, all the fclones are allocated correctly.
>> So use numa_node_id() to limit the allocation to current NUMA node.
> We prefer the allocation to succeed, instead of failing if the current
> NUMA node has no available memory.
Got it.
Thanks
Huang Shijie
>
> Please check:
>
> grep . /sys/devices/system/node/node*/numastat
>
> Are you going to change ~700 uses of NUMA_NO_NODE in the kernel ?
>
> Just curious.
>
>> Signed-off-by: Huang Shijie <shijie@os.amperecomputing.com>
>> ---
>> include/linux/skbuff.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
>> index 2dde34c29203..ebc42b2604ad 100644
>> --- a/include/linux/skbuff.h
>> +++ b/include/linux/skbuff.h
>> @@ -1343,7 +1343,7 @@ static inline bool skb_fclone_busy(const struct sock *sk,
>> static inline struct sk_buff *alloc_skb_fclone(unsigned int size,
>> gfp_t priority)
>> {
>> - return __alloc_skb(size, priority, SKB_ALLOC_FCLONE, NUMA_NO_NODE);
>> + return __alloc_skb(size, priority, SKB_ALLOC_FCLONE, numa_node_id());
>> }
>>
>> struct sk_buff *skb_morph(struct sk_buff *dst, struct sk_buff *src);
>> --
>> 2.40.1
>>
next prev parent reply other threads:[~2024-02-20 6:26 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-20 2:18 Huang Shijie
2024-02-20 5:32 ` Eric Dumazet
2024-02-20 6:26 ` Shijie Huang [this message]
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)
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=bea860f8-a196-4dff-a655-4da920e2ebfa@amperemail.onmicrosoft.com \
--to=shijie@amperemail.onmicrosoft.com \
--cc=aleksander.lobakin@intel.com \
--cc=ast@kernel.org \
--cc=cl@os.amperecomputing.com \
--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@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
all inboxes | Powered by JetHome®