From: Jason Baron <jbaron@redhat.com>
To: Masami Hiramatsu <mhiramat@redhat.com>
Cc: linux-kernel@vger.kernel.org, mingo@elte.hu,
mathieu.desnoyers@polymtl.ca, hpa@zytor.com, tglx@linutronix.de,
rostedt@goodmis.org, andi@firstfloor.org, roland@redhat.com,
rth@redhat.com, fweisbec@gmail.com, avi@redhat.com
Subject: Re: [PATCH 0/9] jump label v6
Date: Fri, 9 Apr 2010 17:37:01 -0400 [thread overview]
Message-ID: <20100409213701.GC2774@redhat.com> (raw)
In-Reply-To: <4BBF8FC8.9050707@redhat.com>
On Fri, Apr 09, 2010 at 04:36:24PM -0400, Masami Hiramatsu wrote:
> Hi Jason,
>
> Jason Baron wrote:
> > Hi,
> >
> > Refresh of jump labeling patches aginst -tip tree. For bacground see:
> > http://marc.info/?l=linux-kernel&m=125858436505941&w=2
> >
> > I believe I've addressed all the reviews from v5.
> >
> > Changes in v6:
> >
> > * I've moved Steve Rostedt's 'ftrace_dyn_arch_init()' to alternative.c to
> > put it into a common area for used by both ftrace and jump labels. By
> > default we put a 'jmp 5' in the nop slot. Then, when we detect the best
> > runtime no-op we patch over the 'jmp 5' with the appropriate nop.
> >
> > * build time sort of the jump label table. The jump label table is more
> > optimally accessed if the entries are continguous. Sorting the table
> > accomplishes this. Do the sort at build-time. Adds a '-j' option to
> > 'modpost' which replaces the vmlinux, with a sorted jump label section vmlinux.
> > I've tested this on x86 with relocatable and it works fine there as well. Note
> > that I have not sorted the jump label table in modules. This is b/c the jump
> > label names can be exported by the core kernel, and thus I don't have them
> > available at buildtime. This could be solved by either finding the correct
> > ones in the vmlinux, or by embedding the name of the jump label in the module
> > tables (and not just a pointer), but the module tables tend to be smaller, and
> > thus there is less value to this kind of change anyway. The kernel continues to
> > do the sort, just in case, but at least for the vmlinux, this is just a
> > verfication b/c the jump label table has already been sorted.
> >
> > * added jump_label_text_reserved(), so that other routines that want to patch
> > the code, can first verify that they are not stomping on jump label addresses.
>
> Good!:-)
> So now, it might be a good time to integrate those text_reserved() functions.
>
> BTW, how many jumps would you expect modifying at once?
> Since the text_poke_smp() uses stop_machine() for each modifying text,
> I found that it can cause a delay issue if it is called so many times...
> (e.g. a systemtap testcase sets ~5000 probes at once)
>
> Thank you,
>
I'm counting 934 jump label locations in the vmlinux, i have compiled,
675 of them being 'kmalloc'. Batch mode for text_poke_smp()?
-Jason
next prev parent reply other threads:[~2010-04-09 21:37 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-09 19:49 [PATCH 0/9] jump label v6 Jason Baron
2010-04-09 19:49 ` [PATCH 1/9] jump label: notifier atomic call chain notrace Jason Baron
2010-04-09 19:49 ` [PATCH 2/9] jump label: base patch Jason Baron
2010-04-09 19:49 ` [PATCH 3/9] jump label: x86 support Jason Baron
2010-04-09 19:49 ` [PATCH 4/9] jump label: tracepoint support Jason Baron
2010-04-09 19:49 ` [PATCH 5/9] jump label: add module support Jason Baron
2010-04-09 19:49 ` [PATCH 6/9] jump label: move ftrace_dyn_arch_init to common code Jason Baron
2010-04-09 19:49 ` [PATCH 7/9] jump label: sort jump table at build-time Jason Baron
2010-04-09 21:24 ` Vivek Goyal
2010-04-09 21:32 ` Roland McGrath
2010-04-09 19:50 ` [PATCH 8/9] jump label: initialize workqueue tracepoints *before* they are registered Jason Baron
2010-04-09 19:50 ` [PATCH 9/9] jump label: jump_label_text_reserved() to reserve our jump points Jason Baron
2010-04-09 21:09 ` Masami Hiramatsu
2010-04-09 20:36 ` [PATCH 0/9] jump label v6 Masami Hiramatsu
2010-04-09 21:37 ` Jason Baron [this message]
2010-04-09 21:58 ` Masami Hiramatsu
2010-04-10 6:16 ` David Miller
2010-04-10 6:22 ` H. Peter Anvin
2010-04-13 16:56 ` Mathieu Desnoyers
2010-04-14 19:34 ` Jason Baron
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=20100409213701.GC2774@redhat.com \
--to=jbaron@redhat.com \
--cc=andi@firstfloor.org \
--cc=avi@redhat.com \
--cc=fweisbec@gmail.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@polymtl.ca \
--cc=mhiramat@redhat.com \
--cc=mingo@elte.hu \
--cc=roland@redhat.com \
--cc=rostedt@goodmis.org \
--cc=rth@redhat.com \
--cc=tglx@linutronix.de \
/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