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, 29 Sep 2011 21:40:18 -0300
From:	Arnaldo Carvalho de Melo <acme@...stprotocols.net>
To:	David Ahern <dsahern@...il.com>
Cc:	Jiri Olsa <jolsa@...hat.com>, a.p.zijlstra@...llo.nl,
	mingo@...e.hu, Stephane Eranian <eranian@...gle.com>,
	paulus@...ba.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] perf tools: Exit recording if events have non matching
 sample type

Em Thu, Sep 29, 2011 at 05:33:42PM -0600, David Ahern escreveu:
> On 09/29/2011 05:06 PM, Arnaldo Carvalho de Melo wrote:
> >> >From what I can see sample_type has to be the same for all samples:
> >> https://lkml.org/lkml/2011/8/15/6

> > We could add a PERF_SAMPLE_ID2 that if present would be guaranteed
> > to be the last, or we can, as PeterZ prefers/suggests, to use one
> > mmap per sample id, then we know that if we're getting it on that
> > mmap, it has that sample_type.

> > For record that means we need to dump each per-sample_id mmap onto a
> > separate file, i.e. use a directory, etc.
 
> That seems like a major re-write of perf. Why not keep the existing
> restriction and have users who want different sample_types run
> multiple perf commands?
 
> What's to be gained by refactoring the code to support multiple
> sample_types in a single command invocation?

This comes from time to time:

http://us.generation-nt.com/answer/bug-perf-event-sampling-buffer-format-cannot-handle-multi-event-sampling-help-202985832.html

The whole point of sample_type is to ask for just what is needed for
some specific event so that we reduce the per sample footprint.

So we allow for multiple types of events to be on the same stream, but
not for them to have just what each need, its a limitation, one that we
can solve. I see no reason not to solve it :-)

The evsel/evlist classes were designed to abstract away such details,
i.e. perf_evlist__mmap should notice different sample_types and sort
this out transparently.

And then perf_evlist__mmap_read(evlist, idx), evlist->nr_mmaps should be
enough to process the events :-)

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ