> > Well the facts talk for themselves. Linux 2.2.12 running on a single
> > processor is able to context switch in around 1us. A user level thread
> > system which is already built and tested and works perfectly can do a
> > context switch in 55ns !!!
>
> Hrmm, this really makes me curious about
> the size of the chunks of work you let
> the threads do :)
>
What does the size of the thread work have to do with context switching when
merely all the processor registers are saved on the context switch??
> If there is a free processor, it will be used. Linux knows
> how much time it costs to move a thread from one CPU to an
> other (cache flush time) and can make quite informed
> decisions about when to move a process to where.
>
> Imagine you did have CPU binding and one of your 4 threads
> was interrupted by sometihing else in the system. Wouldn't
> it be better if Linux shared that extra load over all 4
> processors letting everything proceed in a fair speed?
> (this is what Linux currently does)
Yes but once a thread is allocated to one processor it is a strategy that is
should not migrate it to another processor exactly due to cache consistency.
Then what happens if all threads on the process are on one processor ?? No
advantage at all. Also if the thread is interrupted by something else in the
system then Linux knows best and will be allowed to schedule the
interruptions as it sees fit. Yet I am not about rewriting the Linux
scheduler I am on about scheduling my threads as I see fit
Regards
Joseph Cordina
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/dmentre/smp-howto/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]