Messages in this thread | ![/](/images/icornerl.gif) | | Subject | Re: ACPI/HT or Packet Scheduler BUG? | From | jamal <> | Date | Sat, 16 Apr 2005 12:04:07 -0400 |
| |
On Sat, 2005-16-04 at 13:34 +0200, Thomas Graf wrote: > * 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.
The rule of "optimize for the common" fails miserably in this case because this is not a common case/usage of qdiscs. I have a feeling though that the patch went in due to dude-optimizing-loopback as pointed by Herbert. It could also be it was done because RCU-is-so-cool. I dont recall. Maybe worth reverting to the earlier scheme if it is going to continue to be problematic.
cheers, jamal
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |