On Thu, 10 Jun 1999, Emil Briggs wrote:
> A very bad slowdown -- it's not just the scheduling and cache issues.
> Each thread does some dynamic memory allocation -- if I let a very
> large number of threads run concurrently I run out of RAM and start
> swapping. I tried running with the number of CPU's set to a large
> value to test scheduler/cache issues but I can only get to 100 or
> so on the Linux boxes we have before swapping starts. I do see some
> effects but nothing dramatic.
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?
-- mingo
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
