Re: Best CPU chipset for Linux? (was: [Lhms-devel] [PATCH 0/7]Fragmentation Avoidance V19)

[Linus Torvalds]

On Sun, 6 Nov 2005, John Stoffel wrote:
> 
> Has any vendor come close to the ideal CPU architecture for an OS?  I
> would assume that you'd want:

Well, in the end, the #1 requirement ends up being "wide availability of 
development boxes".

For example, I think Apple made a huge difference to the PowerPC platform, 
and we'll see what happens when Apple boxes are x86. Can IBM continue to 
make Power available enough to be relevant.

Note that raw numbers of CPU's don't much matter - ARM sells a lot more 
than x86, but it's not to developers. Similarly, the game consoles may 
sell a lot of Power, but the actual developers that are using it is a very 
specialized bunch and much smaller in number.

> 	1. large address space, 64 bits
> 	2. large IO space, 64 bits
> 	3. high memory/io bandwidth
> 	4. efficient locking primitives?
> 	   - keep some registers for locking only?
> 	5. efficient memory bandwidth?
> 	6. simple setup where you don't need so much legacy cruft?
> 	7. clean CPU design?  RISC?  Is CISC king again?
> 	8. Variable page sizes?
> 	   - how does this affect TLB?
> 	   - how do you change sizes in a program?
>         9. SMP or hyper-threading or multi-cores?	   
>        10. PCI (and it's flavors) addressing/DMA support?

It's personal, but I don't think the above are huge deal-breakers.

We do want a "big enough" virtual address space, that's pretty much 
required. It doesn't necessarily have to be the full 64 bits, and it's 
fine if the IO space is just a part of that.

As to ISA and registers - nobody much cares. The compiler takes care of 
it, and I'd personally _much_ rather see a common ISA than a "clean" one. 
The x86 architecture may be odd, but it works well.

So the ISA doesn't matter that much, but from a microarchitectural 
standpoint:

 - fast large first-level caches help a lot. And I'd rather take a bigger 
   L1 that has a two- or even three-cycle latency than a small one. That's 
   assuming the uarch is out-of-order, of course.

 - good fast L2, and I'll take low-latency memory access over an L3 any 
   day. 

 - low-latency serialization (locking and memory barriers). In fact, 
   pretty much low-latency everything (branch mispredict latency etc). 

 - cheap and powerful.

but the fact is, we'll work with pretty much any crap we're given. If it's 
bad, it won't make it in the marketplace.

		Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/