Thread (43 messages) 43 messages, 5 authors, 2009-08-04

Re: [RFC] [PATCH] Don't run __qdisc_run() on a stopped TX queue

From: Jarek Poplawski <hidden>
Date: 2009-07-29 11:26:19

On Wed, Jul 29, 2009 at 07:11:34PM +0800, Herbert Xu wrote:
On Wed, Jul 29, 2009 at 11:04:36AM +0000, Jarek Poplawski wrote:
quoted
How about this: instead of the _RUNNING flag we take tx lock while
holding qdisc lock and release qdisc lock just after (before xmit).
This should prevent reordering, and probably could improve cache use:
CPU B which takes qdisc lock only for enqueuing now, would use it for
dequeuing too, plus if accidentally the next xmit goes to a different
tx queue, it could start before CPU A finishes. Otherwise it would
simply wait for CPU A (without tx lock contention). Of course it
needs testing... 
Well reordering isn't the only problem, the lock contention brought
upon by two CPUs both trying to transmit the same flow from the
qdisc is just as bad.
If you mean the tx lock there should be no "real" contention: only
one waiter max. qdisc lock's contention might be higher, but it's
use (during contention) better: enqueue + dequeue together instead
of doing it separately.

Cheers,
Jarek P.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help