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

[Avi Kivity <avi@redhat.com>]

On 12/19/2011 01:40 PM, Ingo Molnar wrote:
>
> 2) the proper solution: creating a 'user-space vmalloc()' that 
>    is per mm and that gets inherited transparently, across 
>    fork() and exec(), and which lies outside the regular vma
>    spaces. On 64-bit this should be straightforward.

That probably has uses outside perf too, but I can see mm nacks piling up.

>    These vmas are not actually 'known' to user-space normally -
>    the kernel PMU code knows about it and does what we do with
>    PEBS: flushes it when necessary and puts it into the
>    regular perf event channels.
>
>    This solves the inherited perf record workflow immediately:
>    the parent task just creates the buffer, which gets inherited 
>    across exec() and fork(), into every portion of the workload.

The buffer still needs to be managed.  While you may be able to juggle
different threads on the same cpu using different events, threads on
other cpus need to use separate LWP contexts and buffers.

>
>    System-wide profiling is a small additional variant of this: 
>    creating such a user-vmalloc() area for all tasks in the
>    system so that the PMU code has them ready in the 
>    context-switch code.

What about security?  Do we want to allow any userspace process to mess
up the buffers?  It can even reprogram the LWP block, so you're counting
different things, or at higher frequencies, or into other processes
ordinary vmas?

You could rebuild the LWP block on every context switch I guess, but you
need to prevent access to other cpus' LWP blocks (since they may be
running other processes).  I think this calls for per-cpu cr3, even for
threads in the same process.

> Solution #2 has the additional advantage that we could migrate 
> PEBS to it and could allow interested user-space access to the 
> 'raw' PEBS buffer as well. (currently the PEBS buffer is only 
> visible to kernel-space.)

That's probably useful for jits.

> I'd suggest the easy hack first, to get things going - we can 
> then help out with the proper solution.

I think you're underestimating the complexity there.  LWP wasn't
designed for this.

-- 
error compiling committee.c: too many arguments to function