From: David Ahern <dsahern@kernel.org>
To: Xin Long <lucien.xin@gmail.com>,
Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: Eric Dumazet <edumazet@google.com>,
"David S . Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
netdev@vger.kernel.org, eric.dumazet@gmail.com,
Willem de Bruijn <willemb@google.com>,
Coco Li <lixiaoyan@google.com>
Subject: Re: [PATCH net] tcp: fix skb_copy_ubufs() vs BIG TCP
Date: Thu, 27 Apr 2023 20:13:37 -0600 [thread overview]
Message-ID: <3cfdd719-900b-88cf-3fe4-fb277e68325f@kernel.org> (raw)
In-Reply-To: <CADvbK_eX0t9KGuhdERweue3BkefVtzZx-ZQBVhfe8jb1aO6eZw@mail.gmail.com>
On 4/27/23 6:40 PM, Xin Long wrote:
>
> I just ran David's test scripts in a metal machine:
>
> There seem memleak with this patch, and the performance is impaired too:
>
> # free -h
> total used free shared buff/cache
> available
> Mem: 31Gi 999Mi 30Gi 12Mi 303Mi
> 30Gi
I can confirm the memleak; thanks for noticing that. It is really easy
to reproduce on a real nic by just running tcpdump with large tso packets.
>
> I could also see some call trace:
>
> [ 271.416989] warn_alloc: 640 callbacks suppressed
> [ 271.417006] lt-iperf3: page allocation failure: order:1,
> mode:0x820(GFP_ATOMIC), nodemask=(null),cpuset=/,mems_allowed=0-1
> [ 271.432684] CPU: 1 PID: 2218 Comm: lt-iperf3 Tainted: G S
> 6.3.0.net0 #10
> [ 271.440783] Hardware name: Supermicro
> X9DRH-7TF/7F/iTF/iF/X9DRH-7TF/7F/iTF/iF, BIOS 3.2 06/04/2015
> [ 271.449831] Call Trace:
> [ 271.452276] <IRQ>
> [ 271.454286] dump_stack_lvl+0x36/0x50
> [ 271.457953] warn_alloc+0x11b/0x190
> [ 271.461445] __alloc_pages_slowpath.constprop.119+0xcb9/0xd40
> [ 271.467192] __alloc_pages+0x32d/0x340
> [ 271.470944] skb_copy_ubufs+0x11b/0x630
I did not trigger this ... perhaps due to memory pressure from the leak?
performance wise, veth hits the skb_copy_ubufs when the packet crosses
the namespace, so ZC performance (with and without hugepages ) lags
non-ZC for the same host use case.
next prev parent reply other threads:[~2023-04-28 2:13 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-27 19:24 [PATCH net] tcp: fix skb_copy_ubufs() vs BIG TCP Eric Dumazet
2023-04-27 21:08 ` David Ahern
2023-04-27 21:21 ` Willem de Bruijn
[not found] ` <CADvbK_eX0t9KGuhdERweue3BkefVtzZx-ZQBVhfe8jb1aO6eZw@mail.gmail.com>
2023-04-28 2:13 ` David Ahern [this message]
2023-04-28 4:19 ` Eric Dumazet
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=3cfdd719-900b-88cf-3fe4-fb277e68325f@kernel.org \
--to=dsahern@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=eric.dumazet@gmail.com \
--cc=kuba@kernel.org \
--cc=lixiaoyan@google.com \
--cc=lucien.xin@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=willemb@google.com \
--cc=willemdebruijn.kernel@gmail.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).