linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@suse.com>
To: <npiggin@kernel.dk>
Cc: <linux-kernel@vger.kernel.org>
Subject: ticket spin locks vs. interrupt re-enabling during spin loops
Date: Fri, 13 Jan 2012 16:30:50 +0000	[thread overview]
Message-ID: <4F106A4A020000780006C90E@nat28.tlf.novell.com> (raw)

Hi Nick,

prior to your introduction of ticket locks on x86 interrupts would get
re-enabled in what was then called __raw_spin_lock_flags(). While I
realize that this is tricky with ticket locks, have you ever thought
through what it would take to implement this correctly?

We had this working well in our Xen kernels up to 2.6.39, but the
changes to try_to_wake_up() in 3.0 uncovered a problem with the
original implementation, and so I'm now struggling with finding a
solution that can cover both this problem as well as to another
possible scenario I meanwhile thought of that would break with
the original code (an open coded spinning loop over spin_trylock()
continuing until success in a scenario similar to that in the new
try_to_wake_up()). A draft implementation that I had put
together today isn't working quite right yet (and hence I can't
quantify its performance impact at all).

One fundamental question of course is whether this really is worth
it at all, since re-enabling interrupts here inherently implies that
tickets may need to be dropped, and hence the fairness they are
intended to guarantee is being undermined. But keeping interrupts
frequently disabled for virtually indefinite periods of time (as can
happen in a CPU over-committed virtualized environment) is
certainly a problem that's worth considering solutions for.

Jan


                 reply	other threads:[~2012-01-13 16:29 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=4F106A4A020000780006C90E@nat28.tlf.novell.com \
    --to=jbeulich@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=npiggin@kernel.dk \
    /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).