All of lore.kernel.org
 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 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.