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-next>] [day] [month] [year] [list]
Date:	Mon, 5 May 2014 22:52:45 -0400 (EDT)
From:	Nicolas Pitre <nicolas.pitre@...aro.org>
To:	Sonny Rao <sonnyrao@...omium.org>
cc:	linux-arm-kernel@...ts.infradead.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Douglas Anderson <dianders@...omium.org>,
	Olof <olofj@...omium.org>, Stephane Eranian <eranian@...gle.com>,
	Bhaskar Janakiraman <bjanakiraman@...omium.org>
Subject: Re: CPU performance counters not working on big.LITTLE switcher

On Mon, 5 May 2014, Sonny Rao wrote:

> Hi, we have the problem today that cpu based performance counters don't
> work when we're using the big.LITTLE switcher on Exynos 5420, and it
> doesn't look like code exists to deal with this in the switcher.
> 
> As it stands right now, if you put an A-15 or A-7 PMU node into your
> device-tree on an bl_switcher system it's very broken.  At the minimum, I
> think it should disable performance counters until there's some kind of
> proper implementation.
> 
> I looked into trying to make this work, but it turned out to not be as
> simple as just context switching counters from A-15 to A-7.  The biggest
> problem is that the PMUs are not architecturally compatible.  There are
> different events and differing numbers of counters on these two cores.
>  There's also the tangential issue of representing this in the device tree,
> but that's far less important.
> 
> My guess as to how to fix this is to create an "architectural" PMU which
> contains the intersection of the two performance monitor units with the
> minimum number of counters supported by either core (which in this case
> looks to be 4 on the A7).  However, I don't really have the bandwidth to
> work on this at  the moment.  I was mostly wondering, have other people run
> into this limitation and is there any sort of plan to work on it?

The Linaro kernel release from a year ago or so contained a hack to make 
PMUs available and cope with the switcher.

However, the ultimate solution is to add multi-PMU support in a generic 
way to the kernel and let user space see both A15 and A7 counters.  It 
is then up to the analysis tools to consolidate (some of) them if 
wanted.  And this would work whether the switcher is used, or even when 
the scheduler has learned to do proper task placement for b.L systems 
where tasks may migrate across clusters.

Someone at ARM indicated they'd be working on the multi-PMU support if I 
remember correctly.  For that reason, Linaro stopped maintaining the 
initial hack since it was a lot of work to keep it working on top of 
later kernels and a better solution was coming anyway.  I don't know 
what the status of that work is though.


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