On Thu, 10 Jun 1999, Emil Briggs wrote:
> The application that I am thinking of is a numerical solver for
> Schrodingers equation. The algorithm has a very natural parallel
> breakdown -- use one thread per electron in the physical system.
> Depending on the physical system being simulated you can have anywhere
> from 1 to hundreds of electrons (threads). In places fine grained
> synchronization of the threads is required while in other spots they can
> run for long periods of time independently. It would make the code much
> simpler if I could change the thread-scheduling policy to FIFO in the
> independent sections. Each thread has a large data set and I can have
> hundreds trying to run at the same time which doesn't work to well. To
> get around this I schedule everything explicitly and adjust the number
> of threads running (or trying to run) depending on the number of CPU's
> in the system.
what kind of slowdown do you get if you set the number of CPUs to a much
larger value than the number of CPUs available? (this should simulate the
'no hand-scheduling' case correctly, right?) How many reschedules per
second do you get in this case (look at vmstat 1 output) - and how many do
you get if you have hand-scheduling turned on. What i'd like to know is
the exact cause of the slowdown - scheduler overhead due to large
nr_running, cache trashing, both, or something else?
-- 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]
