Thread (5 messages) flat view 5 messages, 3 authors, 2025-03-20

Re: tc: network egress frozen during qdisc update with debug kernel

From: Jamal Hadi Salim <jhs@mojatatu.com>
Date: 2025-03-19 21:05:19
Also in: rcu

Possibly related (same subject, not in this thread)

On Wed, Mar 19, 2025 at 2:12 PM Breno Leitao [off-list ref] wrote:
On Wed, Mar 19, 2025 at 09:05:07AM -0700, Paul E. McKenney wrote:
quoted
quoted
I think we should redesign lockdep_unregister_key() to work on a separately
allocated piece of memory,
then use kfree_rcu() in it.

Ie not embed a "struct lock_class_key" in the struct Qdisc, but a pointer to

struct ... {
     struct lock_class_key;
     struct rcu_head  rcu;
}
Works for me!
I've tested a different approach, using synchronize_rcu_expedited()
instead of synchronize_rcu(), given how critical this function is
called, and the command performance improves dramatically.

This approach has some IPI penalties, but, it might be quicker to review
and get merged, mitigating the network issue.

Does it sound a bad approach?

Date:   Wed Mar 19 10:23:56 2025 -0700

    lockdep: Speed up lockdep_unregister_key() with expedited RCU synchronization

    lockdep_unregister_key() is called from critical code paths, including
    sections where rtnl_lock() is held. When replacing a qdisc in a network
    device, network egress traffic is disabled while __qdisc_destroy() is
    called for every queue. This function calls lockdep_unregister_key(),
    which was blocked waiting for synchronize_rcu() to complete.

    For example, a simple tc command to replace a qdisc could take 13
    seconds:

      # time /usr/sbin/tc qdisc replace dev eth0 root handle 0x1234: mq
        real    0m13.195s
        user    0m0.001s
        sys     0m2.746s
Could you please add the "after your change"  output as well?

cheers,
jamal
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help