> 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 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. > 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. Alan _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
