From: Thomas Graf <tgraf@suug.ch>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Steven Rostedt <rostedt@goodmis.org>,
hadi@cyberus.ca, netdev <netdev@oss.sgi.com>,
Tarhon-Onu Victor <mituc@iasi.rdsnet.ro>,
kuznet@ms2.inr.ac.ru, devik@cdi.cz, linux-kernel@vger.kernel.org,
Patrick McHardy <kaber@trash.net>,
"David S. Miller" <davem@davemloft.net>
Subject: Re: ACPI/HT or Packet Scheduler BUG?
Date: Sat, 16 Apr 2005 13:34:46 +0200 [thread overview]
Message-ID: <20050416113446.GJ4114@postel.suug.ch> (raw)
In-Reply-To: <20050416112329.GA31847@gondor.apana.org.au>
* Herbert Xu <20050416112329.GA31847@gondor.apana.org.au> 2005-04-16 21:23
> On Sat, Apr 16, 2005 at 01:06:39PM +0200, Thomas Graf wrote:
> >
> > It's not completely useless, it speeds up the deletion classful
> > qdiscs having some depth. However, it's not worth the locking
> > troubles I guess.
>
> RCU is meant to optimise the common reader path. In this case
> that's the packet transmission code. Unfortunately it fails
> miserably when judged by that criterion.
There is one case where it can do good for latency which is for
per flow qdiscs or any other scenarios implying hundreds or
thousands of leaf qdiscs where a destroyage of one such qdisc
tree will take up quite some cpu to traverse all the classes
under dev->queue_lock. I don't have any numbers on this, but
I don't completely dislike the method of hiding the qdiscs under
the lock and do the expensive traveling unlocked.
next prev parent reply other threads:[~2005-04-16 11:34 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.4.61.0504081225510.27991@blackblue.iasi.rdsnet.ro>
[not found] ` <Pine.LNX.4.61.0504121526550.4822@blackblue.iasi.rdsnet.ro>
[not found] ` <Pine.LNX.4.61.0504141840420.13546@blackblue.iasi.rdsnet.ro>
[not found] ` <1113601029.4294.80.camel@localhost.localdomain>
2005-04-15 21:44 ` ACPI/HT or Packet Scheduler BUG? jamal
2005-04-15 21:54 ` Steven Rostedt
2005-04-15 22:54 ` Thomas Graf
2005-04-16 1:49 ` Herbert Xu
2005-04-16 5:01 ` Steven Rostedt
2005-04-16 11:06 ` Thomas Graf
2005-04-16 11:12 ` Herbert Xu
2005-04-17 17:46 ` Patrick McHardy
2005-04-17 21:37 ` Herbert Xu
2005-04-16 11:23 ` Herbert Xu
2005-04-16 11:34 ` Thomas Graf [this message]
2005-04-16 16:04 ` jamal
2005-04-16 18:21 ` Thomas Graf
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=20050416113446.GJ4114@postel.suug.ch \
--to=tgraf@suug.ch \
--cc=davem@davemloft.net \
--cc=devik@cdi.cz \
--cc=hadi@cyberus.ca \
--cc=herbert@gondor.apana.org.au \
--cc=kaber@trash.net \
--cc=kuznet@ms2.inr.ac.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=mituc@iasi.rdsnet.ro \
--cc=netdev@oss.sgi.com \
--cc=rostedt@goodmis.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).