Re: [RFC patch 08/18] cnt32_to_63 should use smp_rmb()

Mathieu Desnoyers
2008-11-07T21:41:22Z

* Russell King (rmk+lkml@arm.linux.org.uk) wrote:
> On Fri, Nov 07, 2008 at 11:47:58AM -0500, Mathieu Desnoyers wrote:
> > But any get_cycles() user of cnt32_to_63() should be shot down. The
> > bright side is : there is no way get_cycles() can be used with this
> > new code. :)
> >
> > e.g. of incorrect users for arm (unless they are UP only, but that seems
> > like a weird design argument) :
> >
> > mach-sa1100/include/mach/SA-1100.h:#define OSCR __REG(0x90000010)
> > /* OS timer Counter Reg. */
> > mach-sa1100/generic.c: unsigned long long v = cnt32_to_63(OSCR);
> > mach-pxa/include/mach/pxa-regs.h:#define OSCR __REG(0x40A00010) /* OS
> > Timer Counter Register */
> > mach-pxa/time.c: unsigned long long v = cnt32_to_63(OSCR);
>
> It's strange for you to make that assertion when PXA was the exact
> platform that Nicolas created this code for - and that's a platform
> where preempt has been widely used.
>
> The two you mention are both ARMv5 or older architectures, and the
> first real SMP ARM architecture is ARMv6. So architecturally they
> are UP only.
>

Ok. And hopefully they do not execute instructions speculatively ?
Because then a instruction sync would be required between the __m_hi_cnt
read and get_cycles.

If you design such stuff with portability in mind, you'd use per-cpu
variables, which ends up being a single variable in the single-cpu
special-case.

> So, tell me why you say "unless they are UP only, but that seems like
> a weird design argument"? If the platforms can only ever be UP only,
> what's wrong with UP only code being used with them? (Not that I'm
> saying anything there about cnt32_to_63.)

That's fine, as long as the code does not end up in include/linux and
stays in arch/arm/up-only-subarch/.

When one try to create architecture agnostic code (which is what is
likely to be palatable to arch agnostic headers), designing with UP in
mind does not make much sense.

>
> I'd like to see you modify the silicon of a PXA or SA11x0 SoC to add
> more than one processor to the chip - maybe you could use evostick to
> glue two dies together and a microscope to aid bonding wires between
> the two? (Of course, you'd need to design something to ensure cache
> coherence as well, and arbitrate the internal bus between the two
> dies.) ;)
>
> Personally, I think that's highly unlikely.
>

Very unlikely indeed. ;)

Mathieu

> --
> Russell King
> Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
> maintainer of:

--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68