linux-kernel - Re: perf events over (net) console?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 9 Sep 2010 15:07:23 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Harald Gustafsson <hgu1972@...il.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Harald Gustafsson <harald.gustafsson@...csson.com>,
	Song Yuan <song.yuan@...csson.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>
Subject: Re: perf events over (net) console?

* Peter Zijlstra <peterz@...radead.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@...tname record sleep 60
  perf --remote user@...tname 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/