Until now I just listen what others said. Now Drew Eckhardt
suggested two sockets for CPUs. I like this idea but in a slightly
different way. Since I'm not an ee-guy I don't know about technical
issues. But what about a two processor system and who ever likes to
have more cpu-power plugs in another cpu. I like the responsiveness
(is this an english word) of multi-processor machines. Everything
runs much smoother.
Memory bandwidth is the bottleneck on everything but super computers.
Throw two processors at a problem in a shared memory multi-processor
design and not enough cache (remember, we aren't using a second level
cache because of cost reasons) things won't get any faster.
I'm not 100% aware of the impacts to Linux.
I know the best solution will be hard (multi-threaded kernel).
You could *probably* get away with mutexes in appropriate parts
of the kernel, although it would be ugly.
BTW, this will give us in case of a dump frame buffer (didn't we
have the idea of a second cpu for the video before) the scalability
depending on the money one wants to spend for the whole system.
IMHO, the added design complexity in both hardware and software probably
isn't worth it, since our goal is "reasonable performance at a reasonable
If you aren't satisfied with Linux's response :
Basically, operating systems just sit arround and allocate
resources, making tradeoffs between things like fairness,
performance, and response time.
In Linux, we trade off fairness for interactive response time
when we put processes at the head of the run queue when they're
woken up rather than the tail. We trade performance for fairness
when we reserve the last buffer cache requests for reads rather
than writes. We trade performance (ie, minimal scheduler overhead)
for interactive response.
If you feel that Linux isn't responsive enough, change the priorities
(ie, modify the scheduler, buffer cache code, whatever) to suit your