From: Ido Schimmel <idosch@idosch.org>
To: Martin Zaharinov <micron10@gmail.com>
Cc: Eric Dumazet <edumazet@google.com>, netdev <netdev@vger.kernel.org>
Subject: Re: Very slow remove interface from kernel
Date: Tue, 9 May 2023 23:08:20 +0300 [thread overview]
Message-ID: <ZFqoNJqwLjaVFGaa@shredder> (raw)
In-Reply-To: <FE7CE62C-DBEB-4FE1-8ACB-C8B7DAF15710@gmail.com>
On Tue, May 09, 2023 at 09:50:18PM +0300, Martin Zaharinov wrote:
> i try on kernel 6.3.1
>
>
> time for i in $(seq 2 4094); do ip link del link eth1 name vlan$i type vlan id $i; done
>
> real 4m51.633s —— here i stop with Ctrl + C - and rerun and second part finish after 3 min
> user 0m7.479s
> sys 0m0.367s
You are off-CPU most of the time, the question is what is blocking. I'm
getting the following results with net-next:
# time -p for i in $(seq 2 4094); do ip link del dev eth0.$i; done
real 177.09
user 3.85
sys 31.26
When using a batch file to perform the deletion:
# time -p ip -b vlan_del.batch
real 35.25
user 0.02
sys 3.61
And to check where we are blocked most of the time while using the batch
file:
# ../bcc/libbpf-tools/offcputime -p `pgrep -nx ip`
[...]
__schedule
schedule
schedule_timeout
wait_for_completion
rcu_barrier
netdev_run_todo
rtnetlink_rcv_msg
netlink_rcv_skb
netlink_unicast
netlink_sendmsg
____sys_sendmsg
___sys_sendmsg
__sys_sendmsg
do_syscall_64
entry_SYSCALL_64_after_hwframe
- ip (3660)
25089479
[...]
We are blocked for around 70% of the time on the rcu_barrier() in
netdev_run_todo().
Note that one big difference between my setup and yours is that in my
case eth0 is a dummy device and in your case it's probably a physical
device that actually implements netdev_ops::ndo_vlan_rx_kill_vid(). If
so, it's possible that a non-negligible amount of time is spent talking
to hardware/firmware to delete the 4K VIDs from the device's VLAN
filter.
>
>
> Config is very clean i remove big part of CONFIG options .
>
> is there options to debug what is happen.
>
> m
next prev parent reply other threads:[~2023-05-09 20:08 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-09 8:22 Very slow remove interface from kernel Martin Zaharinov
2023-05-09 10:20 ` Ido Schimmel
2023-05-09 10:32 ` Eric Dumazet
2023-05-09 11:10 ` Martin Zaharinov
2023-05-09 12:36 ` Eric Dumazet
2023-05-09 18:50 ` Martin Zaharinov
2023-05-09 20:08 ` Ido Schimmel [this message]
2023-05-09 20:16 ` Martin Zaharinov
2023-05-10 5:31 ` Martin Zaharinov
2023-05-10 6:06 ` Martin Zaharinov
2023-05-10 9:40 ` Eric Dumazet
2023-05-10 13:15 ` Martin Zaharinov
2023-05-25 7:50 ` Martin Zaharinov
2023-05-10 9:16 ` Martin Zaharinov
2023-05-10 9:22 ` Eric Dumazet
2023-05-09 20:08 ` Martin Zaharinov
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=ZFqoNJqwLjaVFGaa@shredder \
--to=idosch@idosch.org \
--cc=edumazet@google.com \
--cc=micron10@gmail.com \
--cc=netdev@vger.kernel.org \
/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).