linux-kernel - Re: [PATCH 0/9] perf: Adding better precise

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: <20130510105536.GA18805@gmail.com>
Date:	Fri, 10 May 2013 12:55:36 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Jiri Olsa <jolsa@...hat.com>, linux-kernel@...r.kernel.org,
	Corey Ashford <cjashfor@...ux.vnet.ibm.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...e.hu>,
	Namhyung Kim <namhyung@...nel.org>,
	Paul Mackerras <paulus@...ba.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Andi Kleen <ak@...ux.intel.com>,
	David Ahern <dsahern@...il.com>,
	Stephane Eranian <eranian@...gle.com>
Subject: Re: [PATCH 0/9] perf: Adding better precise_ip field handling

* Peter Zijlstra <peterz@...radead.org> wrote:

> On Fri, May 10, 2013 at 12:31:12PM +0200, Ingo Molnar wrote:
> > PERF_COUNT_HW_CPU_CYCLES_PRECISE is not a vague request at all: it means 
> > 'get me the most precise cycles profiling available on this system'.
> 
> And how will you interpret the results? Do you know to manually adjust 
> for skid or will you assume the results 'correct'?

Look at the tools/perf/ patches, they don't actually need or use that 
information to adjust for skid!

If user-space wants _that_ level of control because it wants to correct 
for skid (if there's skid), or if it wants to display to the user how 
precise the profiling is, then they can do the (much) more complex probing 
dance.

What is absolutely indefensible is to not give a good shortcut for the 
most common case of 'give me the most precise cycles event you got'...

> I see such a feature only causing confusion; I told it to be precise, 
> therefore this register op after the memory load really is the more 
> expensive thing.

You are creating confusion where there's none: "give me the best profiling 
you've got" is a pretty reasonable thing to ask.

The thing is, there's variations in the quality of profiling between CPUs, 
sometimes even between CPU models. 99.999% of the people don't care about 
that, because 99.9% of the time the profile is unambiguous: functions are 
typically big enough, with the overhead somewhere in the middle, so skid 
just doesn't matter.

So to 'solve' this corner case information you worry about to extract 
(which cannot be solved - there's more profiling artifacts and imprecision 
than skid) you sacrifice the thing that _DOES_ matter: for the kernel to 
offer our best profiling feature as easily as possible...

What explanation do you have for that failure?

> People generally don't volunteer to think, you have to force them to -- 
> even if that makes them complain.

It is a mistake to 'force' people to consider stuff _they don't care about 
in 99% of the cases_.

Thanks,

	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/