> Yes, Paul, we know you like non-coherent memory... ;-)
> ...
> The problem is, that if you're doing something funky, and of only limited
> applicability, the economics will kill you. The whole point of ARM
> microservers is that the will (hopefully) be *cheap*.
>

IMHO (I have no test case to prove), there is some improvement which can be done
on the cache system: it seems an over-simplification to consider all the memory
is used in the same way.
My favorite example is caching of the screen frame-buffer: caching continuous line of 32/64 bytes is non efficient if you represent a char as group of non continuous pixels (i.e. separated by a line of pixels corresponding to the other chars on the line).
But talking of servers, caching the same way memory which is used locally by the processor, the memory which is used to DMA to/from the external world (network packets,...) and the memory which is shared in between processors (hopefully coherent) may be non optimal; some ARM may be better (have more assembly instructions) to synchronize the cache to some defined level or to reserve a line without reading it first...
Anyway ARM microserver may win, but the quality of the software will be an important part of this success; on the ARM software I am working on, drivers look more like a set of files glued together which happen to work last time it was tested. The management of power supply and switchable clocks for each sub-device in the system-on-chip shared in between u-boot and Linux is not "fully" quality engineered.

Etienne.