Messages in this thread |  | | | Date | Thu, 9 Sep 2010 15:07:23 +0200 | | From | Ingo Molnar <> | | Subject | Re: perf events over (net) console? |
| |
* 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
|  |