From: Jamal Hadi Salim <jhs@mojatatu•com>
To: Eric Dumazet <eric.dumazet@gmail•com>, netdev <netdev@vger•kernel.org>
Cc: John Fastabend <john.fastabend@gmail•com>,
Kevin Athey <kda@google•com>, Xiaotian Pei <xiaotian@google•com>
Subject: Re: [RFC net-next] net: sched: do not acquire qdisc spinlock in qdisc/class stats dump
Date: Sun, 22 May 2016 12:30:11 -0400 [thread overview]
Message-ID: <5741DE93.7090202@mojatatu.com> (raw)
In-Reply-To: <1463661320.18194.178.camel@edumazet-glaptop3.roam.corp.google.com>
On 16-05-19 08:35 AM, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google•com>
>
> Large tc dumps (tc -s {qdisc|class} sh dev ethX) done by Google BwE host
> agent [1] are problematic at scale :
>
> For each qdisc/class found in the dump, we currently lock the root qdisc
> spinlock in order to get stats. Sampling stats every 5 seconds from
> thousands of HTB classes is a challenge when the root qdisc spinlock is
> under high pressure.
>
Good stuff.
There are other optimization we could do in such large scale dumps
(such as not dumping something that hasnt been updated)
Could we have changed it to be rcu?
> These stats are using u64 or u32 fields, so reading integral values
> should not prevent writers from doing concurrent updates if the kernel
> arch is a 64bit one.
>
Meaning it wont work on other archs? is atomic read not dependable
on other setups?
> Being able to atomically fetch all counters like packets and bytes sent
> at the expense of interfering in fast path (queue and dequeue packets)
> is simply not worth the pain, as the values are generally stale after 1
> usec.
>
> These lock acquisitions slow down the fast path by 10 to 20 %
>
Acked-by: Jamal Hadi Salim <jhs@mojatatu•com>
cheers,
jamal
prev parent reply other threads:[~2016-05-22 16:30 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-19 12:35 [RFC net-next] net: sched: do not acquire qdisc spinlock in qdisc/class stats dump Eric Dumazet
2016-05-19 16:08 ` Alexei Starovoitov
2016-05-19 17:02 ` Eric Dumazet
2016-05-20 1:50 ` Cong Wang
2016-05-20 2:45 ` Eric Dumazet
2016-05-20 5:23 ` Cong Wang
2016-05-20 5:50 ` Eric Dumazet
2016-05-22 16:35 ` Jamal Hadi Salim
2016-05-20 12:44 ` Eric Dumazet
2016-05-20 13:01 ` Eric Dumazet
2016-05-20 13:09 ` Eric Dumazet
2016-05-20 23:38 ` David Miller
2016-05-22 16:30 ` Jamal Hadi Salim [this message]
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=5741DE93.7090202@mojatatu.com \
--to=jhs@mojatatu$(echo .)com \
--cc=eric.dumazet@gmail$(echo .)com \
--cc=john.fastabend@gmail$(echo .)com \
--cc=kda@google$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=xiaotian@google$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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