Re: [RFC 4/5] x86, perf: implements lwp-perf-integration (rc1)

[Ingo Molnar <mingo@elte.hu>]

* Joerg Roedel <joro@8bytes.org> wrote:

> On Tue, Dec 20, 2011 at 07:40:04PM +0100, Ingo Molnar wrote:
> 
> > > I am fine with integrating LWP into perf as long as it makes 
> > > sense and does not break the intended usage scenario for LWP.
> > 
> > That's the wrong way around - in reality we'll integrate LWP 
> > upstream only once it makes sense and works well with the 
> > primary instrumentation abstraction we have in the kernel.
> 
> I still don't see why you want an abstraction for a hardware 
> feature [...]

Because if done properly then Linux users and developers will be 
able to utilize the hardware feature well beyond the limited 
scope these patches are giving it.

A couple of examples:

1) This command:

      perf record -e lwp:instructions ./myapp

   will be possible and will be able to do skid-less profiling.

2) In the long run apps might be able to insert lightweight 
   trace entries without entering the kernel, using the LWPINS 
   instruction.

3) Maybe LWP will be enhanced with the ability to profile system 
   mode execution as well - which we'll be able to support very 
   easily.

These features are *far* more interesting than some limited 
self-monitoring use of LWP.

I don't mind niches per se, so i don't mind the self-monitoring 
usecase either, as long as they are not trying to be the *only* 
feature, at the expense of more interesting features.

I think it can all be supported in a consistent way (see my 
previous mails) - but the feature as presented today just does 
not look useful enough to me if only supports that niche 
self-monitoring usecase.

> > > [...] It also destroys the intended use-case for LWP 
> > > because it disturbs any process that is doing 
> > > self-profiling with LWP.
> > 
> > Why would it destroy that? Self-profiling can install events 
> > just fine, the kernel will arbitrate the resource.
> 
> Because you can't reliably hand over the LWPCB management to 
> the kernel. The instruction to load a new LWPCB is executable 
> in ring-3. Any kernel-use of LWP will never be reliable.

It will be reliable for all tasks that don't intentionally 
modify their own LWPCB's but stay with the defined APIs and no 
task will be able to destroy *another* task's LWPCB (be it in or 
outside of any APIs), if properly implemented.

So a task can mess with itself - and it can already do that 
today.

So what's your point?

> > > So what you are saying is (not just here, also in other 
> > > emails in this thread) that every hardware not designed 
> > > for perf is crap?
> > 
> > No - PMU hardware designed to not allow the profiling of the 
> > kernel is obviously a crappy aspect of it. Also, PMU 
> > hardware that does not allow 100% encapsulation by the 
> > kernel is obviously not very wisely done either.
> 
> Why? Whats wrong with user-space having control over its own 
> PMU in a safe way? This is what the feature was designed for.

Read what i've written: 'PMU hardware designed to not allow the 
profiling of the kernel is obviously a crappy aspect of it'.

There is no reason why LWP could not allow profiling of kernel 
execution as well, with a simple security model to make sure 
unprivileged user-space does not profile kernel execution: such 
as a LWP-load-time check whether the LWPCB lies on a system pte 
or not.

This would allow everything that is possible today - and more.

Allowing user-space access to the PMU does not preclude a proper 
PMU abstraction.

Thanks,

	Ingo