Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)
On 01/19/2010 07:47 PM, Jim Keniston wrote: This is still with a kernel entry, yes? Yes, this involves setting a breakpoint and trapping into the kernel when it's hit. The 6-7x figure is with the current 2-trap approach (breakpoint, single-step). Boosting could presumably make that more like 12-14x. A trap is IIRC ~1000 cycles, we can reduce this to ~50 (totally negligible from the executed code's point of view). Do you have plans for a variant that's completely in userspace? I don't know of any such plans, but I'd be interested to read more of your thoughts here. As I understand it, you've suggested replacing the probed instruction with a jump into an instrumentation vma (the XOL area, or something similar). Masami has demonstrated -- through his djprobes enhancement to kprobes -- that this can be done for many x86 instructions. What does the code in the jumped-to vma do? 1. Write a trace entry into shared memory, trap into the kernel on overflow. 2. Trap if a condition is satisfied (fast watchpoint implementation). Is the instrumentation code that corresponds to the uprobe handlers encoded in an ad hoc .so? Looks like a good idea, but it doesn't matter much to me. -- error compiling committee.c: too many arguments to function
Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)
On Wed, 2010-01-20 at 11:43 +0200, Avi Kivity wrote: 1. Write a trace entry into shared memory, trap into the kernel on overflow. 2. Trap if a condition is satisfied (fast watchpoint implementation). So now you want to consume more of a process' address space to store trace data as well? Not to mention that that process could wreck the trace data rendering it utterly unreliable.
Re: linux-next: add utrace tree
On Wed, Jan 20, 2010 at 12:10:26PM +0530, Ananth N Mavinakayanahalli wrote: It will cause conflicts with various other trees and increases the overhead all around. It also causes us to trust linux-next bugreports less - as it's not the 'next Linux' anymore. Also, there's virtually no high-level technical review done in linux-next: the trees are implicitly trusted (because they are pushed by maintainers), bugs and conflicts are reported but otherwise it's a neutral tree that includes pretty much any commit indiscriminately. If you need review and testing there's a number of trees you can get inclusion into. So would -tip be one of them? If so could you pull the utrace-ptrace branch in? Or did you intend some other tree (random-tracing)? (Though I think a ptrace reimplementation isn't 'random'-tracing :-)) Heh. No this is a tree I use for, well, random tracing patches indeed, which has extended to random tracing/perf/* patches by the time. I sometimes relay other's patches to Ingo toward this tree but this is usually about small volumes and for small term storage: patches that have been reviewed/acked already. utrace/uprobe is about high volume and longer time debate/review/maintainance and I won't have the time to carry this. Ananth
Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)
On Wed, Jan 20, 2010 at 12:06:20PM +0530, Srikar Dronamraju wrote: * Frederic Weisbecker fweis...@gmail.com [2010-01-19 19:06:12]: On Tue, Jan 19, 2010 at 09:47:45AM -0800, Jim Keniston wrote: What does the code in the jumped-to vma do? Is the instrumentation code that corresponds to the uprobe handlers encoded in an ad hoc .so? Once the instrumentation is requested by a process that is not the instrumented one, this looks impossible to set a uprobe without a minimal voluntary collaboration from the instrumented process (events sent through IPC or whatever). So that looks too limited, this is not anymore a true dynamic uprobe. I dont see a case where the thread being debugged refuses to place a probe unless the process is exiting. The traced process doesnt decide if it wants to be probed or not. There could be a slight delay from the time the tracer requested to the time the probe is placed. But this delay in only affecting the tracer and the tracee. This is in contract to say stop_machine where the threads of other applications are also affected. I did not think about a kind of trace point inserted in a shared memory. I was just confused :)
Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)
On 01/20/2010 11:57 AM, Peter Zijlstra wrote: On Wed, 2010-01-20 at 11:43 +0200, Avi Kivity wrote: 1. Write a trace entry into shared memory, trap into the kernel on overflow. 2. Trap if a condition is satisfied (fast watchpoint implementation). So now you want to consume more of a process' address space to store trace data as well? Yes. I know I'm bad. Not to mention that that process could wreck the trace data rendering it utterly unreliable. It could, but it also might not. Are we going to deny high performance tracing to users just because it doesn't work in all cases? Note this applies to any kind of monitoring or debugging technology. A process can be influenced by the debugger and render any debug info you get out of it unreliable. One non-timing example is a process using a checksum of its text as an input to some algorithm. -- error compiling committee.c: too many arguments to function
Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)
On 01/20/2010 12:45 PM, Srikar Dronamraju wrote: What does the code in the jumped-to vma do? 1. Write a trace entry into shared memory, trap into the kernel on overflow. 2. Trap if a condition is satisfied (fast watchpoint implementation). That looks to be a nice idea. We should certainly look into this possibility. However can we look at this option probably a little later? Our plan was to do one step at a time i.e have the basic uprobes in first and target the booster (i.e jump to the next instruction without the need for single-stepping next). We could look at this option of using jump instead of int3 after we are done with the booster. Hope that's okay. I'm all for incremental development and merging, as long as we keep the interfaces flexible enough for the future. -- error compiling committee.c: too many arguments to function
Re: linux-next: add utrace tree
Hi - On Wed, Jan 20, 2010 at 05:59:59PM +1100, Stephen Rothwell wrote: [...] Including experimental code that is RFC and which is not certain to go upstream is certainly not the purpose of linux-next though. Ingo is correct in what he says here. See the boilerplate: [...] Basically, this should be just what you would send to Linus (or ask him to fetch). I will remove this tree from linux-next tomorrow and wait until it is more ready for mainline inclusion. Please reconsider. Ingo mistook what was being proposed. We request merge/integration testing for just the set of patches posted http://lkml.org/lkml/2009/12/17/466, which was in response to peterz's earlier review comments, and none of which is labeled or considered RFC or experimental. Ananth was right that the utrace-ptrace git branch represents this rather than master. - FChE pgpQGsDelG5SS.pgp Description: PGP signature
Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)
Peter Zijlstra pet...@infradead.org writes: With CPL2 or RPL on user segments the protection issue seems to be manageable for running the instructions from kernel space. Nope -- it doesn't work on 64bit and even on 32bit can have large costs on some CPUs. Also designing 32bit only features in 2010 would seem rather unfortunate. -Andi -- a...@linux.intel.com -- Speaking for myself only.
Re: [RFC] [PATCH 1/7] User Space Breakpoint Assistance Layer (UBP)
Frederic Weisbecker wrote: On Tue, Jan 19, 2010 at 09:47:45AM -0800, Jim Keniston wrote: Do you have plans for a variant that's completely in userspace? I don't know of any such plans, but I'd be interested to read more of your thoughts here. As I understand it, you've suggested replacing the probed instruction with a jump into an instrumentation vma (the XOL area, or something similar). Masami has demonstrated -- through his djprobes enhancement to kprobes -- that this can be done for many x86 instructions. What does the code in the jumped-to vma do? Is the instrumentation code that corresponds to the uprobe handlers encoded in an ad hoc .so? Once the instrumentation is requested by a process that is not the instrumented one, this looks impossible to set a uprobe without a minimal voluntary collaboration from the instrumented process (events sent through IPC or whatever). So that looks too limited, this is not anymore a true dynamic uprobe. Agreed. Since uprobe's handler must be running in kernel, we need to jump into kernel space anyway. Booster (just skips a single-stepping(trap) exception) may be useful for improving uprobe performance. And also as Andi said, using jump instead of int3 in userspace has 2GB address space limitation. It's not a problem for kernel inside, but a big problem in userspace. Thank you, -- Masami Hiramatsu Software Engineer Hitachi Computer Products (America), Inc. Software Solutions Division e-mail: mhira...@redhat.com
Re: linux-next: add utrace tree
Frank, please be clear as to which branch you want included (master or utrace-ptrace). Also note that neither of those branches matches what was posted in the sense that they both have lots of history and merges not represented in the patches. (I assume that they do produce the same final source tree, though). Yes, the trees do match. I certainly never expected our ancient git history to get merged in directly upstream. I've made a new branch on: git://git.kernel.org/pub/scm/linux/kernel/git/frob/linux-2.6-utrace.git called: next/master (Actually it's on master.kernel.org and the public mirror is being a little slow as I write this.) This starts from v2.6.33-rc4 and then has commits for the 7 patches that Oleg posted in December. Beyond that, we've added one follow-on patch to fix a bug Oleg just tracked down (Oleg will post that patch soon). And I've added one more commit with a MAINTAINERS update, shown below. You can also find the same stuff from the series file and patch files in: http://people.redhat.com/utrace/2.6-next/ If it makes things easier for linux-next to have this git branch either rebased or merged from a different fork point, please let me know. Thanks, Roland --- [PATCH] MAINTAINERS: add utrace This updates the ptrace entry to cover utrace too. They are part of the same maintenance effort. Also add the utrace mailing list. Signed-off-by: Roland McGrath rol...@redhat.com --- MAINTAINERS |7 +-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index c8f47bf..8da2a0a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4375,15 +4375,18 @@ M: Jim Paris j...@jtan.com L: cbe-oss-...@ozlabs.org S: Maintained -PTRACE SUPPORT +PTRACE AND UTRACE SUPPORT M: Roland McGrath rol...@redhat.com M: Oleg Nesterov o...@redhat.com +L: utrace-devel@redhat.com S: Maintained F: include/asm-generic/syscall.h F: include/linux/ptrace.h F: include/linux/regset.h F: include/linux/tracehook.h -F: kernel/ptrace.c +F: include/linux/utrace.h +F: kernel/ptrace* +F: kernel/utrace* PVRUSB2 VIDEO4LINUX DRIVER M: Mike Isely is...@pobox.com
