>
>we have gang scheduling ... does no-one read source-code anymore? :)
>
I had read that code -- it didn't look to me like it addressed the
situation that I was referring to. Maybe I didn't explain what I
meant well enough. I was thinking of parallel applications (typically
numeric simulations) that require fine grained synchronization. Suppose
I have 8 threads. If one of them get's scheduled to run then I'm not
going to get very good performance unless all 8 are running concurrently
on different CPU's. So I beleive the SGI solution was to boost the priority
of all 8 threads if one of them get's scheduled to run. There were still
problems with this and it took them some time to come up with a fix that
worked well in a production environment though.
>> 2. I have sometimes wanted to use FIFO or RR scheduling within a
>> set of threads -- I'm not talking about actual realtime scheduling
>> against all process's on the system but only within a group of threads.
>
>what particular effect do you want to achieve? Note that the current
>scheduler does prefer to switch within the same 'thread group' (or rather,
>threads belonging to the same VM object) to get better TLB (and other
>cache) locality - although this is not very aggressive right now. (mainly
>because no-one has yet shown an application that could benefit from
>anything different)
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.
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]
