netdev - Re: [PATCH v3 08/10] ARM: mxs: add ocotp read function

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:	Wed, 5 Jan 2011 18:35:09 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Jamie Lokier <jamie@...reable.org>
Cc:	Jamie Iles <jamie@...ieiles.com>, gerg@...pgear.com,
	B32542@...escale.com, netdev@...r.kernel.org,
	s.hauer@...gutronix.de, bryan.wu@...onical.com, baruch@...s.co.il,
	w.sang@...gutronix.de, r64343@...escale.com,
	Shawn Guo <shawn.guo@...escale.com>, eric@...rea.com,
	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>, davem@...emloft.net,
	linux-arm-kernel@...ts.infradead.org, lw@...o-electronics.de
Subject: Re: [PATCH v3 08/10] ARM: mxs: add ocotp read function

On Wed, Jan 05, 2011 at 05:56:17PM +0000, Jamie Lokier wrote:
> cpu_relax() is a hint to the CPU to, for example, save power or be
> less aggressive on the memory bus (to save power or be fairer).
> 
> Currently these architectures do more than just a barrier in cpu_relax():
> x86, IA64, PowerPC, Tile and S390.
> 
> Although it's just a hint on ARM at the moment, it might change in
> future - especially with power mattering on so many ARM systems.
> (Even now, just changing it to a very short udelay might save power
> on existing ARMs without breaking drivers.)

I think that's a matter for what the loop is doing.  If it's polling
a memory location then it probably has no effect what so ever.  If
the loop is spinning on a device, then the CPU will have to wait for
the read to complete which will slow it down.

It's something that would need very careful evaluation, and is probably
something that's very platform and loop specific.

> By the way, I see ARM defines cpu_relax as smp_mb() on arch >= 6.  Is
> that correct and useful?  On other architectures*, barrier() is enough
> of a barrier, but it's conceivable that smp_mb() would have some
> ARM-specific fairness or bus activity benefit - in which case it
> should probably be mb().

See a discussion last year with Linus.  It's there to ensure that one CPU
spinning on a variable can see a write by another CPU to that same
variable.  Without the barrier, the visibility effects are unbounded on
ARMv6 - and it's only like that for ARMv6, not >= ARMv6.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html