From: Eric Dumazet <eric.dumazet@gmail.com>
To: Michel Lespinasse <walken@google.com>
Cc: Rik van Riel <riel@redhat.com>,
Steven Rostedt <rostedt@goodmis.org>,
linux-kernel@vger.kernel.org, aquini@redhat.com,
lwoodman@redhat.com, jeremy@goop.org,
Jan Beulich <JBeulich@novell.com>,
Thomas Gleixner <tglx@linutronix.de>,
Tom Herbert <therbert@google.com>
Subject: Re: [RFC PATCH 3/3 -v2] x86,smp: auto tune spinlock backoff delay factor
Date: Thu, 27 Dec 2012 06:27:28 -0800 [thread overview]
Message-ID: <1356618448.30414.948.camel@edumazet-glaptop> (raw)
In-Reply-To: <CANN689HeTk0jNJb4sF_0t714MvFnU0vLw0=JeXYRUwMx8GDnXQ@mail.gmail.com>
On Wed, 2012-12-26 at 22:07 -0800, Michel Lespinasse wrote:
> If we go with per-spinlock tunings, I feel we'll most likely want to
> add an associative cache in order to avoid the 1/16 chance (~6%) of
> getting 595Mbit/s instead of 982Mbit/s when there is a hash collision.
>
> I would still prefer if we could make up something that didn't require
> per-spinlock tunings, but it's not clear if that'll work. At least we
> now know of a simple enough workload to figure it out :)
Even with a per spinlock tuning, we can find workloads where holding
time depends on the context.
For example, complex qdisc hierarchy typically use different times on
enqueue and dequeue operations.
So the hash sounds good to me, because the hash key could mix both lock
address and caller IP ( __builtin_return_address(1) in
ticket_spin_lock_wait())
next prev parent reply other threads:[~2012-12-27 14:27 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-21 23:49 [RFC PATCH 0/3] x86,smp: make ticket spinlock proportional backoff w/ auto tuning Rik van Riel
2012-12-21 23:50 ` [RFC PATCH 1/3] x86,smp: move waiting on contended lock out of line Rik van Riel
2012-12-22 3:05 ` Steven Rostedt
2012-12-22 4:40 ` Michel Lespinasse
2012-12-22 4:48 ` Rik van Riel
2012-12-23 22:52 ` Rafael Aquini
2012-12-21 23:51 ` [RFC PATCH 2/3] x86,smp: proportional backoff for ticket spinlocks Rik van Riel
2012-12-22 3:07 ` Steven Rostedt
2012-12-22 3:14 ` Steven Rostedt
2012-12-22 3:47 ` Rik van Riel
2012-12-22 4:44 ` Michel Lespinasse
2012-12-23 22:55 ` Rafael Aquini
2012-12-21 23:51 ` [RFC PATCH 3/3] x86,smp: auto tune spinlock backoff delay factor Rik van Riel
2012-12-21 23:56 ` [RFC PATCH 3/3 -v2] " Rik van Riel
2012-12-22 0:18 ` Eric Dumazet
2012-12-22 2:43 ` Rik van Riel
2012-12-22 0:48 ` Eric Dumazet
2012-12-22 2:57 ` Rik van Riel
2012-12-22 3:29 ` Eric Dumazet
2012-12-22 3:44 ` Rik van Riel
2012-12-22 3:33 ` Steven Rostedt
2012-12-22 3:50 ` Rik van Riel
2012-12-26 19:10 ` Eric Dumazet
2012-12-26 19:27 ` Eric Dumazet
2012-12-26 19:51 ` Rik van Riel
2012-12-27 6:07 ` Michel Lespinasse
2012-12-27 14:27 ` Eric Dumazet [this message]
2012-12-27 14:35 ` Rik van Riel
2012-12-27 18:41 ` Jan Beulich
2012-12-27 19:09 ` Rik van Riel
2013-01-03 9:05 ` Jan Beulich
2013-01-03 13:24 ` Steven Rostedt
2013-01-03 13:35 ` Eric Dumazet
2013-01-03 15:32 ` Steven Rostedt
2013-01-03 16:10 ` Eric Dumazet
2013-01-03 16:45 ` Steven Rostedt
2013-01-03 17:54 ` Eric Dumazet
2012-12-27 18:49 ` Eric Dumazet
2012-12-27 19:31 ` Rik van Riel
2012-12-29 0:42 ` Eric Dumazet
2012-12-29 10:27 ` Michel Lespinasse
2013-01-03 18:17 ` Eric Dumazet
2012-12-22 0:47 ` [RFC PATCH 3/3] " David Daney
2012-12-22 2:51 ` Rik van Riel
2012-12-22 3:49 ` Steven Rostedt
2012-12-22 3:58 ` Rik van Riel
2012-12-23 23:08 ` Rafael Aquini
2012-12-22 5:42 ` Michel Lespinasse
2012-12-22 14:32 ` Rik van Riel
2013-01-02 0:06 ` ticket spinlock proportional backoff experiments Michel Lespinasse
2013-01-02 0:09 ` [PATCH 1/2] x86,smp: simplify __ticket_spin_lock Michel Lespinasse
2013-01-02 15:31 ` Rik van Riel
2013-01-02 0:10 ` [PATCH 2/2] x86,smp: proportional backoff for ticket spinlocks Michel Lespinasse
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=1356618448.30414.948.camel@edumazet-glaptop \
--to=eric.dumazet@gmail.com \
--cc=JBeulich@novell.com \
--cc=aquini@redhat.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lwoodman@redhat.com \
--cc=riel@redhat.com \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=therbert@google.com \
--cc=walken@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®