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 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.