linux-kernel - Re: [BUG] perf stat: explicit grouping yields unexpected results

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]

Message-ID: <20131117034134.GA19762@tassilo.jf.intel.com>
Date:	Sat, 16 Nov 2013 19:41:34 -0800
From:	Andi Kleen <ak@...ux.intel.com>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Stephane Eranian <eranian@...gle.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Jiri Olsa <jolsa@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	"mingo@...e.hu" <mingo@...e.hu>, David Ahern <dsahern@...il.com>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Namhyung Kim <namhyung.kim@....com>
Subject: Re: [BUG] perf stat: explicit grouping yields unexpected results

> I'd say that the default behavior should be what Jiri implemented: get 
> the most out of the situation and inform. But you are right in that 
> 'forcing' all elements of a group to be valid should be possible as 
> well - if a special perf stat option or event format is used.

When something is multiplexed it can have a very 
large measurement error. For workloads that fluctuate quite a bit, and the
fluctuations do not line up well with the multiplexing interval,
the default scaling does not give good results.

So you expect to get good data, but you get very bad data.

When collecting data for a large number of events it is important
to group them correctly, so that events that are directly dependent
on each other in equations are properly grouped.

When explicit groups were added the user likely considered this 
problem, so it's not good to silently override the choices.

If a user doesn't care they can always not use groups.

> Even in that second case it shouldn't say <unsupported> for everything 
> in the result, but should deny the run immediately and return with an 
> error, and should tell the user how many events in the group fit and 
> which ones didn't.

Returning this information would be great, but it would really 
need an extended errno, or just a error string reported out.

-Andi

-- 
ak@...ux.intel.com -- Speaking for myself only
--
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/