All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Jason Baron <jbaron@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Michael Ellerman <michael@ellerman.id.au>,
	Jan Glauber <jang@linux.vnet.ibm.com>,
	David Daney <ddaney@caviumnetworks.com>,
	"David S. Miller" <davem@davemloft.net>
Subject: Jump Label initialization
Date: Wed, 28 Sep 2011 19:14:52 -0700	[thread overview]
Message-ID: <4E83D49C.9080809@goop.org> (raw)

Hi all,

I'm trying to use the jump label machinery as part of the pv ticketlock
work I'm doing on x86.

The problem I'm having at the moment is that I do my spinlock setup in
smp_prepare_boot_cpu(), which happens before jump_label_init() gets
called, and so the latter goes and nops out all my enabled jump label key.

I'm experimenting at the moment with a patch to allow
jump_label_enable() to be called fairly early, and have that be
respected by jump_label_init().  I'm doing this by replacing
arch_jump_label_poke_text_early() with
arch_jump_label_transform_early(), which shares most of its code with
its non-early variant, except that it expects to run in a pre-SMP
environment.

Does this seem plausible? (I haven't tested it yet.)

The x86, mips and sparc patches are fairly simple; I forgot to look at
powerpc, and I didn't fully investigate s390.

While my current use-case is x86-specific, it seems generally useful to
make the jump_label machinery available as early as possible. I wonder
if you have any suggestions about how to handle this?

Thanks,
    J

             reply	other threads:[~2011-09-29  2:14 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-29  2:14 Jeremy Fitzhardinge [this message]
2011-09-29  2:28 ` Jump Label initialization David Miller
2011-09-29  7:37 ` Peter Zijlstra
2011-09-29 22:20   ` Jeremy Fitzhardinge
2011-09-29 22:23     ` Steven Rostedt
2011-09-29 12:04 ` Jan Glauber
2011-09-29 12:40   ` Steven Rostedt
2011-09-29 13:10     ` Jan Glauber
2011-09-29 16:45   ` Jeremy Fitzhardinge
2011-09-29 17:06     ` David Daney

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=4E83D49C.9080809@goop.org \
    --to=jeremy@goop.org \
    --cc=davem@davemloft.net \
    --cc=ddaney@caviumnetworks.com \
    --cc=jang@linux.vnet.ibm.com \
    --cc=jbaron@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael@ellerman.id.au \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    /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.