On Tue, Jun 25, 2013 at 03:13:29PM +0300, Adrian Hunter wrote: > On 25/06/13 14:23, Stephane Eranian wrote: > > On Mon, Jun 24, 2013 at 3:16 PM, Adrian Hunter <adrian.hun...@intel.com> > > wrote: > >> Sample types need not be identical to determine > >> the sample id from the event. Only the position > >> of the sample id needs to be the same. > >> > >> Compatible sample types are ones in which the bits > >> defined by PERF_COMPAT_MASK are the same. > >> 'perf_evlist__config()' forces sample types to be > >> compatible on that basis. > >>
nice idea > > This is indeed a major flaw of the current sampling buffer format. > > I have a patch coming to address this from the kernel side. > > > > I am trying to understand this patch and I am confused by the > > description and especially the structure of COMPAT_MASK. > > > > I agree that if the SAMPLE_ID position remains constant then > > it can be extracted from the body of the sample uniformly. > > The only way to guarantee a fixed position is by ensuring that > > all the sample_types before SAMPLE_ID and either set or > > unset. By before I don't mean in the enum order but in the > > order in which the kernel lays them various sample_types > > in the buffer. And that's determined by perf_output_sample(). > > So I don't understand why PERF_SAMPLE_CPU and > > PERF_SAMPLE_STREAM_ID are here. > > > > Any explanation? +1 for more comments in changelog and code ;-) > > There are 2 sample formats: one for sample events and one for other events > (the id sample). In perf tools refer __perf_evsel__parse_sample() vs > perf_evsel__parse_id_sample(). For non sample events the ID info is stored backwards via: __perf_event__output_id_sample kernel func. Why do you use PERF_SAMPLE_STREAM_ID in this case instead of the PERF_SAMPLE_ID as for sample events.. ? apart from one more condition in __perf_evsel__calc_is_pos function. AFAICS PERF_SAMPLE_STREAM_ID holds same id value as PERF_SAMPLE_ID, but I guess it has some other meaning.. if not for now, maybe meant something else for the future ;-) not sure jirka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
