On Fri, 10 Dec 1999, jcordina wrote:
> > You dont have enough information. Suppose you have 4 threads one per CPU
> > (locked to the cpu) and one of them takes a lock. Just then a hard real
> time
> > video process is started and sits on that cpu at 100% load. Your entire
> > thread suite comes to a halt.
> >
> > When that occurs with the kernel doing threads the threads will end up
> bouncing
> > a little but across the 3 remaining cpus and still running
> >
>
> First of all the scheduler is aimed for fine grained parallel threads and
> thus something like video processing would never occur since the application
> is in mind when writing this scheduler. Also why should the whole thread
> suite come to a halt.? When one processor is taken up, the other processors
> would go on. If you mean that the three other threads are blocked until the
> first thread is finished, then that would happen even in the kernel. If one
> CPU is taken up processing then the others would simply go on running
> threads and descheduling by calling the scheduler. I guess there is some
> misunderstanding here though
>
> Cheers
>
> Joseph Cordina
What he was worried about was locking 4 processes to 4 specific cpus.
Then one acquires a critical lock, and that process gets displaced by
something of higher priority. The other three would then hang if they
try to acquire this lock, and the process holding the lock would be unable
to prempt one of the blocked processes to finish up and release the lock.
I don't like the idea of locking a process to a cpu. Cray Research
has/had a user-space scheduler as you suggest, but they dropped it right
on top of the normal kernel scheduler without this business of locking a
process to a specific cpu. That worked ok. Taking too much control can
be a bad thing...
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/dmentre/smp-howto/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
