>hm, here the kernel cannot help much i think. It looks like to me that for
>your application we really want to 'hand tune' which thread can run,
>individually. We'd still get swapping problems if we just specified some
>'only N but arbitrary threads can run at once' rule. So you really want to
>'specify N well-defined threads to run at once'. Now, the number of those
>threads should be rather low, correct? Where and how exactly does the
>Linux scheduler get in your way if you do this hand-picking of runnable
>threads?
With hand-scheduling it doesn't get in the way. I usually only run as
many threads as processors since there is no performance advantage to
running more. Having a FIFO policy restricted to a group of threads
would have simplified the coding though since only as many threads
as processors could be running at any one time.
I agree that this isn't something that would matter to many people. It is
nice though that I can make modifications for my own purposes. (Unlike
the case with SGI that I mentioned earlier where we had to wait 6 months
for a fix). While the FIFO scheduling isn't that relevant to anyone else
the concurrency control is important in a time-shared batch environment
on a large machine. (Like a department level compute server).
Emil
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
