On Mon, Sep 15, 2014 at 12:24:27AM +0100, One Thousand Gnomes wrote:
> > So a problem that no one has ever complained about on _any_ arch is suddenly
> > a problem on a subset of Alpha cpus, but a problem I know exists on Alpha
> > isn't important because no one's filed a bug about it?
>
> Yes - because if you think about it that tells you that nobody is hitting
> it with the old code and it probably doesn't matter.
>
> > The only Alpha person in this discussion has come out clearly in favor
> > of dropping EV4/5 support.
>
> That's not a statistically valid sample size btw
OK, adding the other two Alpha Port maintainers on CC.
Attempted summary for their benefit:
o There was a bug involving older Alpha CPUs using 32-bit
memory-reference operations to do smaller memory accesses.
The suggested resolution was to use set_bit().
o Peter Hurley called out a number of theoretical issues with
CPUs lacking 8-bit and 16-bit memory-reference instructions,
for example, adjacent 8-bit variables protected by different
locks not being safe on such CPUs.
o Michael Cree pointed out that some of these issues actually
happen in the X server ever since the libpciaccess change.
Michael would like to compile for Alpha with BWX (thus allowing
8-bit and 16-bit memory references, but disallowing pre-EV56
CPUs) in order make the X server (and thus Debian) work
better on newer Alpha CPUs.
Given that Michael Cree maintains the list of Alpha systems
running Linux, I took this as my cue to provide a couple of
patches to that effect.
o Michael Cree also noted that pre-EV56 Alpha CPUs really can
do 8-bit and 16-bit accesses in an SMP-safe manner via LL/SC,
but that this requires some hacking on the compilers.
o Alan Cox argued that we should support pre-EV56 Alpha CPUs
without any special defense against issues that might arise
from their lack of 8-bit and 16-bit memory-reference
instructions, as you can see above.
Richard, Ivan, Matt, thoughts from your perspectives as Alpha Port
maintainers?
> Plus as I pointed out (and you ignored) you are shutting out any future
> processors with this kind of oddity, and you have not audited all the
> embedded devices we support or may support in future.
True enough, but then again, the Alpha architects did feel the need to
add 8-bit and 16-bit memory reference instructions in EV56. In addition,
if there are future processors that don't provide 8-bit and 16-bit memory
reference instructions, atomic instructions can be used as a fallback.
This fallback is in fact similar to the set_bit approach.
> > The fact is that the kernel itself is much more parallel than it was
> > 15 years ago, and that trend is going to continue. Paired with the fact
> > that the Alpha is the least-parallel-friendly arch, makes improving
> > parallelism and correctness even harder within kernel subsystems; harder
> > than it has to be and harder than it should be.
> >
> > Linus has repeatedly stated that non-arch code should be as
> > arch-independent as possible
>
> That's why many many years ago we added set_bit() and the other bit
> functions. On sane processors they are very fast. On insane ones they
> work. They understand byte tearing, they understand store ordering (which
> a simple variable does not so you've got to audit all your memory
> barriers too). In many cases they are faster than using memory barriers
> to guide the compiler because they invalidate less and allow the compiler
> more freedom.
>
> All this started because I suggested you use set_bit and friends and for
> some reason you've decided to try and find another way to do it. We have
> the bit operations for a reason. On x86 they are very very fast, on
> uniprocessor anything they are very fast, on multiprocessor in general
> they are very fast, or you are dealing with boxes that have sanity
> problems of other kinds.
Indeed, these email threads do tend to examine alternatives from time
to time. ;-)
Thanx, Paul
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
