linux-kernel - Re: [PATCH] perf: implement recording/reporting per-cpu samples

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, 27 May 2010 18:53:33 -0300
From:	Arnaldo Carvalho de Melo <acme@...stprotocols.net>
To:	Arun Sharma <aruns@...gle.com>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	linux-kernel@...r.kernel.org, mingo@...e.hu, paulus@...ba.org,
	davem@...emloft.net, fweisbec@...il.com
Subject: Re: [PATCH] perf: implement recording/reporting per-cpu samples

Em Thu, May 27, 2010 at 01:54:46PM -0700, Arun Sharma escreveu:
> On Thu, May 27, 2010 at 11:41 AM, Arnaldo Carvalho de Melo
> <acme@...stprotocols.net> wrote:
> > Em Wed, May 05, 2010 at 11:16:12AM -0700, Arun Sharma escreveu:
> >> On Tue, May 04, 2010 at 11:16:38AM +0200, Peter Zijlstra wrote:
> >> > > In a shared multi-core environment, users want to analyze why their
> >> > > program was slow. In particular, if the code ran slower only on
> >> > > certain CPUs due to interference from other programs or kernel
> >> > > threads, they want to know that.

> >> > But for that you use perf record -a, right? So you record all cpus
> >> > allways -- otherwise there is no telling what was happening to make it
> >> > go slow.

> >> The updated patch records the CPU only in the system_wide mode.

> > I think this should be done only if you'll actually need it, as in,
> > "cpu" is one of the sort keys, but that can be done as a followup patch,
> > but there is another thing I think you need to change, see below.

> How would you know if the user is going to sort by cpu at "perf record" time?

Excellent point, but as time goes on we may end up selecting all the
optionally selectable fields, so perhaps we should tell that to record
and then check at report time if it is present?

For instance, PERF_SAMPLE_TIME would be interesting too to check if
there is no reordering of events, etc, but should we have it always
enabled?

If we used something like:

perf record --sort cpu,comm ...

We would be able for instance, to avoid having MMAP events that wouldn't
be used at all, reducing PERF_SAMPLE_TID too, I guess, and then the per
event cost would be reduced, on the other hand, if we want to have
maximum flexibility at 'report' time, we could use:

perf record --sort all

With the default remaining the one we have.

perf record --sort +cpu

could be used to add one field to the set of fields in place, whatever
we get the default to be at any point in time.

perf record could as well, if no --sort is presented, infer a reasonable
one from the set of fields present in sample_type, etc.

Of course the feature implemented as-is by your patch is useful and we
need to support it, it can even be like you posted, but I wanted to
express this feeling about per event cost.

> Thanks for taking care of the second part.

Will try to get it done now and will send for review.

- Arnaldo
--
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/