All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Stephen Hemminger <shemminger@vyatta.com>
Cc: David Miller <davem@davemloft.net>,
	alexander.h.duyck@intel.com, netdev@vger.kernel.org
Subject: Re: [RFC PATCH] net: add additional lock to qdisc to increase enqueue/dequeue fairness
Date: Fri, 21 May 2010 18:44:35 +0200	[thread overview]
Message-ID: <1274460275.2439.469.camel@edumazet-laptop> (raw)
In-Reply-To: <20100521084349.0d6f8f9a@nehalam>

Le vendredi 21 mai 2010 à 08:43 -0700, Stephen Hemminger a écrit :

> What about having a special function (spin_lock_greedy?) that just ignores
> the ticket mechanism and always assumes it has right to next ticket.
> 

I am not sure we want to do this, for a single use case...
Adding a new lock primitive to linux should be really really motivated.

x86 ticket spinlocks are nice because we are sure no cpu is going to
stay forever in this code. For other arches, I dont know how this is
coped.

I thought about this before re-working on this patch, but found it was
easier to slightly change Alexander code, ie adding a regular spinlock
for the slowpath.

We could use cmpxchg() and manipulate several bits at once in fast path.
( __QDISC_STATE_RUNNING, __QDISC_STATE_LOCKED ... ) but making the crowd
of cpus spin on the same bits/cacheline than dequeue worker would
definitely slowdown the worker.




  reply	other threads:[~2010-05-21 16:44 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-23 20:25 [RFC PATCH] net: add additional lock to qdisc to increase enqueue/dequeue fairness Alexander Duyck
2010-03-23 20:31 ` David Miller
2010-03-24  2:12   ` Andi Kleen
2010-03-23 20:40 ` Rick Jones
2010-03-23 20:54 ` Eric Dumazet
2010-03-23 21:18   ` Eric Dumazet
2010-03-23 21:45   ` David Miller
2010-03-23 22:08     ` Duyck, Alexander H
2010-03-24  2:58       ` David Miller
2010-03-24  5:42         ` Eric Dumazet
2010-03-24  6:10           ` David Miller
2010-03-23 22:13     ` Eric Dumazet
2010-05-21 15:43       ` Stephen Hemminger
2010-05-21 16:44         ` Eric Dumazet [this message]
2010-05-21 17:38           ` Stephen Hemminger
2010-05-21 17:40           ` Eric Dumazet
2010-06-02  9:48             ` Eric Dumazet
2010-06-02  9:49             ` [PATCH 1/2 net-next-2.6] net: Define accessors to manipulate QDISC_STATE_RUNNING Eric Dumazet
2010-06-02 10:24               ` David Miller
2010-06-02  9:50             ` [PATCH 2/2 net-next-2.6] net: QDISC_STATE_RUNNING dont need atomic bit ops Eric Dumazet
2010-06-02 10:25               ` David Miller
2010-03-24 14:24 ` [RFC PATCH] net: add additional lock to qdisc to increase enqueue/dequeue fairness Eric Dumazet
2010-05-21 15:08 ` [PATCH] net: add additional lock to qdisc to increase throughput Eric Dumazet
2010-05-21 20:04   ` Duyck, Alexander H
2010-06-02 12:10     ` David Miller
2010-06-02 14:52       ` Eric Dumazet

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=1274460275.2439.469.camel@edumazet-laptop \
    --to=eric.dumazet@gmail.com \
    --cc=alexander.h.duyck@intel.com \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=shemminger@vyatta.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.