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

Ingo Molnar
2011-12-21T12:36:43Z

* 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