[Top] [All Lists]

Re: MIPS R4200 / IDT3081 question

To: riscy@pyramid.com
Subject: Re: MIPS R4200 / IDT3081 question
From: Drew Eckhardt <drew@alta.cs.Colorado.EDU>
Date: Thu, 08 Jul 1993 03:49:40 +0100
Cc: hasse@inf.ethz.ch
In-reply-to: Your message of "Thu, 08 Jul 1993 11:25:56 +0200." <9307080926.AA10491@neptune>
Reply-to: riscy@pyramid.com
Sender: riscy-request@pyramid.com

    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


<Prev in Thread] Current Thread [Next in Thread>