linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Gleb Natapov <gleb@redhat.com>
To: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, Tejun Heo <tj@kernel.org>,
	John Stultz <johnstul@us.ibm.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Peter Zijlstra <peterz@infradead.org>,
	David Howells <dhowells@redhat.com>,
	Andrew Jones <drjones@redhat.com>
Subject: Re: [PATCH 1/1] linux headers: header file(s) changes to enable spinlock use jumplabel
Date: Mon, 20 Feb 2012 11:33:50 +0200	[thread overview]
Message-ID: <20120220093350.GF10038@redhat.com> (raw)
In-Reply-To: <4F41E4C1.9010901@linux.vnet.ibm.com>

On Mon, Feb 20, 2012 at 11:44:25AM +0530, Raghavendra K T wrote:
> On 02/20/2012 10:46 AM, Jeremy Fitzhardinge wrote:
> [...]
> >>>>  So we get following error when we try to include jump_label.h from
> >>>>arch/x86/include/asm/spinlock.h because of cyclic dependency
> >>>><spinlock.h>  ->  <jumplabe.h>  ->  <workque.h>  ->  ...<seqlock.h>  ->  <spinlock.h>
> >>>What about splitting the jump_label_key_deferred stuff into a separate
> >>>jump_label_deferred.h, and just include that where it's needed?
> >>>
> >>Andrew Jones did exactly that (CCed).
> 
> Sorry, did not get it. Tried to search the patch. Is it similar
> work or same work?. Could you please point. shall try both the way
> (current way and jump_label_deferred way). So whichever makes
> maintainer happy, let that go :)
> 
It was not CCed to any ML. I CCed Andrew so he can chime in.

> But does pvlock have to use jump
> >>label? I looked at the code and it is used like paravirt patching. Meaning
> >>it is patched only once on a boot up when XEN is detected. May be use
> >>paravirt patching instead of jump label? What if jump label will want
> >>to use spinlock for some reason in the future (it uses mutex currently)?
> >
> >The point of the pv ticketlocks is to avoid any pvop calls on the
> >lock/unlock fastpath, relegating them to only the slow path.
> >Unfortunately, the pv unlock case can't be identical with the non-pv
> >unlock, and jump_labels are lighter weight and more efficient than pvops.
> >
> >It doesn't matter if jump_labels start using spinlocks; all we need the
> >jump_label machinery to do is patch the jump sites in the code so that
> >one of two execution paths can be selected.  Since all the ticketlock
> >jump_label patching happens before SMP is enabled, there's no problem
> >with changing a lock while a cpu is executing the code.
> >
> 
> I also felt agreeing with Jeremy. seemed to me that latter is more
> performance friendly. no?.
> 

I thought not about pvop, but about alternative().  jump_labels is used
by spinlock to patch out jump into nops It can be done via alternative()
too I think.

> (Hmm. Thinking..  By the way is it not that Jeremy's earlier version
> had implementation similar to what Gleb asked ?)

--
			Gleb.

  reply	other threads:[~2012-02-20  9:34 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-17  8:25 [PATCH 1/1] linux headers: header file(s) changes to enable spinlock use jumplabel Raghavendra K T
2012-02-18 23:21 ` Jeremy Fitzhardinge
2012-02-19  9:24   ` Gleb Natapov
2012-02-20  5:16     ` Jeremy Fitzhardinge
2012-02-20  6:14       ` Raghavendra K T
2012-02-20  9:33         ` Gleb Natapov [this message]
2012-02-20 15:00           ` Andrew Jones
2012-02-20 17:51             ` Raghavendra K T
2012-02-21 15:23               ` Andrew Jones
2012-02-22 11:55                 ` Raghavendra K T
2012-02-22 10:48           ` Raghavendra K T

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=20120220093350.GF10038@redhat.com \
    --to=gleb@redhat.com \
    --cc=dhowells@redhat.com \
    --cc=drjones@redhat.com \
    --cc=jeremy@goop.org \
    --cc=johnstul@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=raghavendra.kt@linux.vnet.ibm.com \
    --cc=tglx@linutronix.de \
    --cc=tj@kernel.org \
    --cc=vatsa@linux.vnet.ibm.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;
as well as URLs for NNTP newsgroup(s).