lkml.org 
[lkml]   [2010]   [Sep]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: perf events over (net) console?
    On Thu, Sep 09, 2010 at 03:07:23PM +0200, Ingo Molnar wrote:
    >
    > * Peter Zijlstra <peterz@infradead.org> wrote:
    >
    > > On Thu, 2010-09-09 at 14:31 +0200, Harald Gustafsson wrote:
    > >
    > > > Sorry for being daft...
    > >
    > > No worries, I'm sure we all qualify at times ;-)
    > >
    > > > >> >
    > > > >> > You need a process context anyway to read the data and send it to
    > > > >> > whatever place you want it.
    > > > >> >
    > > > >> > Putting that in-kernel serves no purpose what so ever.
    > > > >>
    > > > >> But if we bring the splice support, that can be done with minimal
    > > > >> userspace noise. Plus that would work with the usual sockets but not
    > > > >> limited to that.
    > > > >
    > > > > Yes. If we can transform the data over the network without it touching
    > > > > disk, then that would be a sufficiently 'does not disturb other tasks'
    > > > > measurement method.
    > > >
    > > > Thanks for the pointers to more information, and yes my thoughts was
    > > > more about avoiding the data copy then avoiding any processing
    > > > context at all.
    > >
    > > Right, currently you get a single copy with mmap() + write(), once we
    > > manage to fix splice() and actually provide perf-splice() you'd be
    > > able to do zero-copy.
    >
    > I think it would also be very useful to have some sort of tooling help
    > for "low overhead/impact perf recording".
    >
    > If there's a 'target box' and a different 'host box' (where most of
    > development is done, etc.), then there might not be any NFS connection
    > set up to make zero-copy file transfer easy. Doing it over ssh would add
    > overhead.
    >
    > One possible workflow would be to run this on the target/remote box:
    >
    > perf remote
    >
    > And as long as that command is running there, it could be used from the
    > development box (over a trusted local network), using something like:
    >
    > perf --remote <hostname> record sleep 60
    > perf --remote <hostname> stat -a sleep 1
    >
    > these would all do the measurements on the remote box, and the resulting
    > perf.data would be created on the desktop box. Communication would be
    > done via some well-known port.
    >
    > etc.
    >
    > An alternative implementation would be to drive this on the assumption
    > that an ssh connection can be established with the target box - but
    > followup high-volume data transfer would be done over an ordinary TCP
    > connection.
    >
    > I.e. the workflow would be even simpler, something like:
    >
    > perf --remote user@hostname record sleep 60
    > perf --remote user@hostname stat -a sleep 1
    >
    > Internally it would work by executing those commands on the remote box
    > via ssh, and redirecting the output via a TCP connection. (some other
    > details might be needed as well for splice to be usable in such a setup)
    >
    > Would anyone be interested in having (and implementing ;-) this?
    >
    > Ingo



    In the beginning this could wrap into perf record - | perf pipe | netcat
    and so, until we get the splice support.



    \
     
     \ /
      Last update: 2010-09-09 15:23    [W:0.037 / U:300.472 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site