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, 1 Sep 2011 11:21:42 -0400
From:	Vince Weaver <vweaver1@...s.utk.edu>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	Mike Hommey <mh@...ndium.org>, <linux-kernel@...r.kernel.org>
Subject: Re: Problem with perf hardware counters grouping

On Thu, 1 Sep 2011, Peter Zijlstra wrote:

> What happens with your >3 case is that while the group is valid and
> could fit on the PMU, it won't fit at runtime because the NMI watchdog
> is taking one and won't budge (cpu-pinned counter have precedence over
> any other kind), effectively starving your group of pmu runtime.
> 
> Also, we should fix that return to say -EINVAL or so.

UGH!  I just noticed this problem yesterday and was meaning to track it 
down.

This obviously causes PAPI to fail if you try to use the maximum number of 
counters.  Instead of getting EINVAL at open time or even at start time, 
you just silently read all zeros at read time, and by then it's too late 
to do anything useful about the problem because you just missed measuring 
what you were trying to.

Is there any good workaround, or do we have to fall back to trying to 
start/read/stop every proposed event set to make sure it's valid?

This is going to seriously impact performance, and perf_event performance 
is pretty bad to begin with.  The whole reason I was writing the tests to 
trigger this is because PAPI users are complaining that perf_event 
overhead is roughly twice that of perfctr or perfmon2, which I've verified 
experimentally.

Vince

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