Date:	Fri, 29 Jan 2010 08:39:07 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Jim Keniston <jkenisto@...ibm.com>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Tom Tromey <tromey@...hat.com>,
	Kyle Moffett <kyle@...fetthome.net>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	Oleg Nesterov <oleg@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Fr??d??ric Weisbecker <fweisbec@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	linux-next@...r.kernel.org, "H. Peter Anvin" <hpa@...or.com>,
	utrace-devel@...hat.com, Thomas Gleixner <tglx@...utronix.de>
Subject: Re: linux-next: add utrace tree


* Jim Keniston <jkenisto@...ibm.com> wrote:

> > > As previously discussed, boosting would also get rid of the single-step 
> > > trap for most instructions.
> > 
> > Boosting is not in the uprobes patch-set you submitted. Even with it 
> > present it wont get rid of the initial INT3. So basically _best-case_ 
> > (with boosting) XOL-uprobes could roughly break even with a pure emulator 
> > approach ...
> > 
> > That's a big and fundamental difference.
> 
> To be fair, wrt uprobes, emulation and boosting are both in the same state: 
> pretty well understood, but not yet implemented.

So, to sum it up: utrace XOL, which is rather complex already, needs even more 
complexity (which is not yet implemented) than the much simpler common-case 
emulator approach i outlined, just to break even with the performance of the 
much simpler approach.

And you've been justifying the complexity of XOL with its performance 
advantages.

See why i'm unimpressed by that argument?

[ Note, i'm not dismissing it entirely, the complexity of XOL _might_ be fine
  in the future if it brings us real advantages: for example if it avoids
  _ALL_ kernel entries.

  That can be done too, by using the jump-probe technique in user-space. (the
  closest anyone came to proposing this was Avi with the user-space INT3 hack
  - but we can do better than that via the jprobes technique.) At that point
  the advantage of having a pure user-space callback technique combined with
  the advantages of having near full instruction coverage might tip the
  balance. There are other complexities to handle in that case though, like 
  buffering and more. ]

But right now we are nowhere near that stage, and i dont see the path towards 
that either. So i'd much rather see something simpler and get on with these 
IMHO unimportant performance details to the IMO much more important high level 
interface and high level tooling details.

When we merged kprobes ~10 years ago we made the (rather bad) mistake of 
merging a raw, opaque facility and leaving 'the rest' up to some other entity. 
IBM kprobes hackers vanished the day the original kprobes code went upstream 
and the high level entity never truly materialized in-kernel, for nearly a 
decade!

With uprobes we should learn from that painful lesson and bring in the high 
level users of uprobes via 'perf probe' (or any other real user) straight 
away.

Complexity is easy to increase when usage is increasing, it's near impossible 
to reduce when usage is not there. (and it's rather hard to reduce even with 
increasing usage - especially of aspects of the complexity leak out to 
user-space ABIs - which danger XOL has written all over it.)

So the request is simple to sum up: please reduce complexity of the initial 
submission and increase all around utility.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists