From: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@elte.hu>, Steven Rostedt <rostedt@goodmis.org>,
Randy Dunlap <rdunlap@xenotime.net>,
Arnaldo Carvalho de Melo <acme@infradead.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Christoph Hellwig <hch@infradead.org>,
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
Oleg Nesterov <oleg@redhat.com>, Mark Wielaard <mjw@redhat.com>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Andrew Morton <akpm@linux-foundation.org>,
Naren A Devaiah <naren.devaiah@in.ibm.com>,
Jim Keniston <jkenisto@linux.vnet.ibm.com>,
Frederic Weisbecker <fweisbec@gmail.com>,
"Frank Ch. Eigler" <fche@redhat.com>,
Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
LKML <linux-kernel@vger.kernel.org>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Subject: Re: [PATCHv11 2.6.36-rc2-tip 3/15] 3: uprobes: Slot allocation for Execution out of line(XOL)
Date: Thu, 2 Sep 2010 23:17:12 +0530 [thread overview]
Message-ID: <20100902174712.GA14891@linux.vnet.ibm.com> (raw)
In-Reply-To: <1283415812.2059.1825.camel@laptop>
> > Current slot allocation mechanism:
> > 1. Allocate one dedicated slot per user breakpoint. Each slot is big
> > enuf to accomodate the biggest instruction for that architecture. (16
> > bytes for x86).
> > 2. We currently allocate only one page for slots. Hence the number of
> > slots is limited to active breakpoint hits on that process.
> > 3. Bitmap to track used slots.
>
> An alternative method would be to have 1 slot per cpu, and manage the
> slot content using preemption notifiers. That gives you a fixed number
> of slots and an unlimited number of probe points.
>
> If the preemption happens to be a migration you need to rewrite the
> userspace IP to point to the new slot -- if indeed the task was inside
> one when it got preempted -- but that all should be doable.
>
Certainly doable but it has its share of drawbacks.
1. On every probe hit we have to copy the instruction into the
slot, so there is a performance penalty.
2 This might complicate booster probe, because the jump
instruction that follows the original instruction now actually have to
coded every time.
3. Yes migration is an issue esp
- if a thread of the same process that hit a breakpoint is scheduled into the same cpu and that newly scheduled thread hits a breakpoint.
- Something similar can happen if a multithreaded process runs on a
uniprocessor machine.
4. I dont see a need for clearing slots after post processing, but if
we need to clear we then are adding more penalties because not only are
we clearing the slots but the post processing then cant happen in
interrupt context.
5. I think we are covered on the cpu hotplug too, (i.e not sure if we have
to make uprobes cpu hot plug aware.).
6. We would still be allocating a page for the slots. Unless we want
to expand to more slots than available in one page, I dont see the
disadvantages with the current approach.
--
Thanks and Regards
Srikar
next prev parent reply other threads:[~2010-09-02 17:53 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-25 13:41 [PATCHv11 2.6.36-rc2-tip 0/15] 0: Uprobes Patches Srikar Dronamraju
2010-08-25 13:41 ` [PATCHv11 2.6.36-rc2-tip 1/15] 1: mm: Move replace_page() / write_protect_page() to mm/memory.c Srikar Dronamraju
2010-08-25 13:41 ` [PATCHv11 2.6.36-rc2-tip 2/15] 2: uprobes: Breakpoint insertion/removal in user space applications Srikar Dronamraju
2010-09-01 19:38 ` Peter Zijlstra
2010-08-25 13:41 ` [PATCHv11 2.6.36-rc2-tip 3/15] 3: uprobes: Slot allocation for Execution out of line(XOL) Srikar Dronamraju
2010-09-01 20:13 ` Peter Zijlstra
2010-09-03 16:40 ` Srikar Dronamraju
2010-09-03 16:51 ` Peter Zijlstra
2010-09-03 17:26 ` Srikar Dronamraju
2010-09-03 17:41 ` Peter Zijlstra
2010-09-06 5:38 ` Srikar Dronamraju
2010-09-03 17:25 ` Peter Zijlstra
2010-09-02 8:23 ` Peter Zijlstra
2010-09-02 17:47 ` Srikar Dronamraju [this message]
2010-09-03 7:26 ` Peter Zijlstra
2010-09-06 17:59 ` Srikar Dronamraju
2010-09-06 18:20 ` Peter Zijlstra
2010-09-06 18:28 ` Peter Zijlstra
2010-08-25 13:42 ` [PATCHv11 2.6.36-rc2-tip 4/15] 4: uprobes: x86 specific functions for user space breakpointing Srikar Dronamraju
2010-09-03 10:26 ` Andi Kleen
2010-09-03 17:48 ` Srikar Dronamraju
2010-09-03 18:00 ` Peter Zijlstra
2010-09-06 7:53 ` Andi Kleen
2010-09-06 13:44 ` Srikar Dronamraju
2010-09-06 14:16 ` Andi Kleen
2010-09-07 0:56 ` Masami Hiramatsu
2010-08-25 13:42 ` [PATCHv11 2.6.36-rc2-tip 5/15] 5: uprobes: Uprobes (un)registration and exception handling Srikar Dronamraju
2010-09-01 21:43 ` Peter Zijlstra
2010-09-02 8:12 ` Peter Zijlstra
2010-09-03 16:42 ` Srikar Dronamraju
2010-09-03 17:19 ` Peter Zijlstra
2010-09-06 17:46 ` Srikar Dronamraju
2010-09-06 18:15 ` Peter Zijlstra
2010-09-06 18:15 ` Peter Zijlstra
2010-09-07 6:48 ` Srikar Dronamraju
2010-09-07 9:33 ` Peter Zijlstra
2010-09-07 11:51 ` Srikar Dronamraju
2010-09-07 12:25 ` Peter Zijlstra
2010-09-06 18:25 ` Mathieu Desnoyers
2010-09-06 20:40 ` Christoph Hellwig
2010-09-06 21:06 ` Peter Zijlstra
2010-09-06 21:12 ` Christoph Hellwig
2010-09-06 21:18 ` Peter Zijlstra
2010-09-07 12:02 ` Srikar Dronamraju
2010-09-07 16:47 ` Mathieu Desnoyers
2010-09-03 17:27 ` Peter Zijlstra
2010-09-01 21:46 ` Peter Zijlstra
2010-08-25 13:42 ` [PATCHv11 2.6.36-rc2-tip 6/15] 6: uprobes: X86 support for Uprobes Srikar Dronamraju
2010-08-25 13:42 ` [PATCHv11 2.6.36-rc2-tip 7/15] 7: uprobes: Uprobes Documentation Srikar Dronamraju
2010-08-25 13:42 ` [PATCHv11 2.6.36-rc2-tip 8/15] 8: tracing: Extract out common code for kprobes/uprobes traceevents Srikar Dronamraju
2010-08-25 13:43 ` [PATCHv11 2.6.36-rc2-tip 9/15] 9: tracing: uprobes trace_event interface Srikar Dronamraju
2010-08-25 13:43 ` [PATCHv11 2.6.36-rc2-tip 10/15] 10: tracing: config option to enable both kprobe-tracer and uprobe-tracer Srikar Dronamraju
2010-08-26 6:02 ` Masami Hiramatsu
2010-08-27 9:31 ` Srikar Dronamraju
2010-08-27 11:04 ` Masami Hiramatsu
2010-08-27 12:17 ` Srikar Dronamraju
2010-08-27 15:37 ` Masami Hiramatsu
2010-08-27 14:10 ` [PATCHv11a " Srikar Dronamraju
2010-08-25 13:43 ` [PATCHv11 2.6.36-rc2-tip 11/15] 11: perf: list symbols in a dso in ascending order Srikar Dronamraju
2010-08-25 23:21 ` Arnaldo Carvalho de Melo
2010-08-26 4:32 ` Srikar Dronamraju
2010-08-30 8:35 ` [tip:perf/core] perf symbols: List symbols in a dso in ascending name order tip-bot for Srikar Dronamraju
2010-08-25 13:43 ` [PATCHv11 2.6.36-rc2-tip 12/15] 12: perf: show possible probes in a given file Srikar Dronamraju
2010-08-27 14:21 ` [PATCHv11a " Srikar Dronamraju
2010-10-20 9:56 ` Masami Hiramatsu
2010-08-25 13:43 ` [PATCHv11 2.6.36-rc2-tip 13/15] 13: perf: Loop thro each of the maps in a map_group Srikar Dronamraju
2010-08-25 13:44 ` [PATCHv11 2.6.36-rc2-tip 14/15] 14: perf: perf interface for uprobes Srikar Dronamraju
2010-08-25 13:44 ` [PATCHv11 2.6.36-rc2-tip 15/15] 15: perf: Show Potential probe points Srikar Dronamraju
2010-10-29 9:23 ` [PATCHv11 2.6.36-rc2-tip 0/15] 0: Uprobes Patches Christoph Hellwig
2010-10-29 10:48 ` Srikar Dronamraju
2010-11-04 18:45 ` Christoph Hellwig
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=20100902174712.GA14891@linux.vnet.ibm.com \
--to=srikar@linux.vnet.ibm.com \
--cc=acme@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=ananth@in.ibm.com \
--cc=fche@redhat.com \
--cc=fweisbec@gmail.com \
--cc=hch@infradead.org \
--cc=jkenisto@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=mingo@elte.hu \
--cc=mjw@redhat.com \
--cc=naren.devaiah@in.ibm.com \
--cc=oleg@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=rdunlap@xenotime.net \
--cc=rostedt@goodmis.org \
--cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox