concurrent haskell: thread priorities
From what i understand (correct me if I'm wrong): The threaded RT creates an OS thread for each CPU/core on the system and uses them to multiplex userland threads. These are context switched whenever they block/yield/gc and no priorities can be assigned. It seems like we could get some priority based scheduling (and still be slackers) if we allow marked green threads to be strictly associated with a specific OS thread (forkChildIO?). Its not a very good solution, but it seems easy to implement and would be nice for the few problems that really need priority based scheduling. How many of those problems involve having 1 thread running at high/realtime priority? Maybe most?
Hello Neal, Monday, December 22, 2008, 11:07:32 PM, you wrote:
The threaded RT creates an OS thread for each CPU/core on the system and uses them to multiplex userland threads. These are context switched whenever they block/yield/gc and no priorities can be assigned.
not exactly. amount of OS threads created controlled by +RTS -N option to the program; unless program has special function that RTS calls to set up this value they are switched on every minor GC which by default occurs after each 256kb allocated which is rather frequent event
It seems like we could get some priority based scheduling (and still be slackers) if we allow marked green threads to be strictly associated with a specific OS thread (forkChildIO?).
forkOS creates new haskell thread and new OS thread specially for it -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
Bulat Ziganshin wrote:
Hello Neal,
Monday, December 22, 2008, 11:07:32 PM, you wrote:
The threaded RT creates an OS thread for each CPU/core on the system and uses them to multiplex userland threads. These are context switched whenever they block/yield/gc and no priorities can be assigned.
not exactly. amount of OS threads created controlled by +RTS -N option to the program; unless program has special function that RTS calls to set up this value
they are switched on every minor GC which by default occurs after each 256kb allocated which is rather frequent event
It seems like we could get some priority based scheduling (and still be slackers) if we allow marked green threads to be strictly associated with a specific OS thread (forkChildIO?).
forkOS creates new haskell thread and new OS thread specially for it
The docs say that the forkOS thread is still scheduled by the Haskell RT though. What would happen if you bump its priority through FFI? What about this scenario: forkOS = OS thread A1, Haskell Thread A2 forkIO = Haskell thread B Could thread B potentially be run on thread A1? Would the RT yield thread A2 to give time to another Haskell thread?
Neal Alexander wrote:
Bulat Ziganshin wrote:
Hello Neal,
Monday, December 22, 2008, 11:07:32 PM, you wrote:
The threaded RT creates an OS thread for each CPU/core on the system and uses them to multiplex userland threads. These are context switched whenever they block/yield/gc and no priorities can be assigned.
not exactly. amount of OS threads created controlled by +RTS -N option to the program; unless program has special function that RTS calls to set up this value
they are switched on every minor GC which by default occurs after each 256kb allocated which is rather frequent event
It seems like we could get some priority based scheduling (and still be slackers) if we allow marked green threads to be strictly associated with a specific OS thread (forkChildIO?).
forkOS creates new haskell thread and new OS thread specially for it
The docs say that the forkOS thread is still scheduled by the Haskell RT though. What would happen if you bump its priority through FFI?
Probably not much, unless you had specified a larger -N value than the number of cores in your machine, in which case the OS threads are being multiplexed by the OS onto the available cores. In that case the relative priorities of the OS threads would affect the scheduling decisions made by the OS.
What about this scenario:
forkOS = OS thread A1, Haskell Thread A2 forkIO = Haskell thread B
Could thread B potentially be run on thread A1?
No.
Would the RT yield thread A2 to give time to another Haskell thread?
Sure, A2 behaves like any other Haskell thread. Cheers, Simon
Bulat Ziganshin wrote:
Monday, December 22, 2008, 11:07:32 PM, you wrote:
The threaded RT creates an OS thread for each CPU/core on the system and uses them to multiplex userland threads. These are context switched whenever they block/yield/gc and no priorities can be assigned.
not exactly. amount of OS threads created controlled by +RTS -N option to the program; unless program has special function that RTS calls to set up this value
There might be multiple OS threads per CPU, if for example one of the Haskell threads makes a safe foreign call another OS thread takes over running the rest of the Haskell threads on that CPU. When you say "+RTS -N2" all you are saying is "I want to allow up to 2 Haskell threads to run simultaneously". The actual mapping between Haskell threads and OS threads is decided by the RTS, hopefully in a sensible way, within this constraint.
they are switched on every minor GC which by default occurs after each 256kb allocated which is rather frequent event
512Kb by default (caches are bigger these days), and configurable with +RTS -A<size>. Cheers, Simon
It seems like we could get some priority based scheduling (and still be slackers) if we allow marked green threads to be strictly associated with a specific OS thread (forkChildIO?).
I think you want the GHC-only GHC.Conc.forkOnIO Suggestions like this are more motivation for the suggestion [1] to adopt a re-engineered / haskell-based RTS [2]. Tom [1] http://www.reddit.com/r/haskell_proposals/comments/7itaz/simple_robust_maint... [2] http://www.seas.upenn.edu/~lipeng/homepage/papers/lmpjt07hw.pdf
Thomas DuBuisson wrote:
It seems like we could get some priority based scheduling (and still be slackers) if we allow marked green threads to be strictly associated with a specific OS thread (forkChildIO?).
I think you want the GHC-only GHC.Conc.forkOnIO
Suggestions like this are more motivation for the suggestion [1] to adopt a re-engineered / haskell-based RTS [2].
Tom
[1] http://www.reddit.com/r/haskell_proposals/comments/7itaz/simple_robust_maint... [2] http://www.seas.upenn.edu/~lipeng/homepage/papers/lmpjt07hw.pdf
------------------------------------------------------------------------
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
GHC.Conc.forkOnIO is helpful but doest work in this case - it doesn't attach them to the same OS thread.
Neal Alexander wrote:
Thomas DuBuisson wrote:
It seems like we could get some priority based scheduling (and still be slackers) if we allow marked green threads to be strictly associated with a specific OS thread (forkChildIO?).
I think you want the GHC-only GHC.Conc.forkOnIO
GHC.Conc.forkOnIO is helpful but doest work in this case - it doesn't attach them to the same OS thread.
But it does attach the thread to a particular "virtual CPU" in the GHC RTS (we call them "capabilities"), with the intention that a virtual CPU corresponds more or less to a real CPU core. Cheers, Simon
marlowsd:
Neal Alexander wrote:
Thomas DuBuisson wrote:
It seems like we could get some priority based scheduling (and still be slackers) if we allow marked green threads to be strictly associated with a specific OS thread (forkChildIO?).
I think you want the GHC-only GHC.Conc.forkOnIO
GHC.Conc.forkOnIO is helpful but doest work in this case - it doesn't attach them to the same OS thread.
But it does attach the thread to a particular "virtual CPU" in the GHC RTS (we call them "capabilities"), with the intention that a virtual CPU corresponds more or less to a real CPU core.
Every time Simon responds on questions of parallelism and the GHC runtime, I learn something. That indicates to me that we've got a 'bus error' situation with how to effectively use the smp runtime. Simon: time for a multicore FAQ wiki page to gather this knowledge, like we did for the performance tips? Somewhere to paste these insights? -- Don
On Fri, Jan 9, 2009 at 8:22 PM, Don Stewart
Every time Simon responds on questions of parallelism and the GHC runtime, I learn something. That indicates to me that we've got a 'bus error' situation with how to effectively use the smp runtime.
Simon: time for a multicore FAQ wiki page to gather this knowledge, like we did for the performance tips? Somewhere to paste these insights?
A few weeks ago, during the weekly GHC meeting, Simon explained the internals of the threading system to me. Among other things he explained how many threads are run per core, how they are load balanced and migrated between cores. I found it very enlightening. Maybe, that could serve as a basis for a GHCThreadingInternals wiki page. Is #ghc channel logged anywhere? Cheers, Johan
Don Stewart wrote:
marlowsd:
Neal Alexander wrote:
Thomas DuBuisson wrote:
It seems like we could get some priority based scheduling (and still be slackers) if we allow marked green threads to be strictly associated with a specific OS thread (forkChildIO?).
I think you want the GHC-only GHC.Conc.forkOnIO
GHC.Conc.forkOnIO is helpful but doest work in this case - it doesn't attach them to the same OS thread. But it does attach the thread to a particular "virtual CPU" in the GHC RTS (we call them "capabilities"), with the intention that a virtual CPU corresponds more or less to a real CPU core.
Every time Simon responds on questions of parallelism and the GHC runtime, I learn something. That indicates to me that we've got a 'bus error' situation with how to effectively use the smp runtime.
Simon: time for a multicore FAQ wiki page to gather this knowledge, like we did for the performance tips? Somewhere to paste these insights?
Sure, that would be great. One slight problem is that I'm still learning myself how to use parallelism effectively, and the RTS is still changing rapidly. We have a paper in the works that should serve as a good overview of the implementation, but a wiki page would be more suitable for users. If nobody else starts one, I'll try to get to it in the next few weeks. Cheers, Simon
Simon Marlow wrote:
Neal Alexander wrote:
Thomas DuBuisson wrote:
It seems like we could get some priority based scheduling (and still be slackers) if we allow marked green threads to be strictly associated with a specific OS thread (forkChildIO?).
I think you want the GHC-only GHC.Conc.forkOnIO
GHC.Conc.forkOnIO is helpful but doest work in this case - it doesn't attach them to the same OS thread.
But it does attach the thread to a particular "virtual CPU" in the GHC RTS (we call them "capabilities"), with the intention that a virtual CPU corresponds more or less to a real CPU core.
Cheers, Simon
Yea, but you still have the problem with FFI that uses TLS don't you? What about having a forkOnOS version with processor affinity? Or is there a way to "upgrade" a thread created with forkOnIO to Bound. I have a thread with soft real-time requirements that cooperatively yields and uses thread local state. Right now there just doesn't seem to be any options.
Neal Alexander wrote:
Simon Marlow wrote:
Neal Alexander wrote:
Thomas DuBuisson wrote:
It seems like we could get some priority based scheduling (and still be slackers) if we allow marked green threads to be strictly associated with a specific OS thread (forkChildIO?).
I think you want the GHC-only GHC.Conc.forkOnIO
GHC.Conc.forkOnIO is helpful but doest work in this case - it doesn't attach them to the same OS thread.
But it does attach the thread to a particular "virtual CPU" in the GHC RTS (we call them "capabilities"), with the intention that a virtual CPU corresponds more or less to a real CPU core.
Cheers, Simon
Yea, but you still have the problem with FFI that uses TLS don't you? What about having a forkOnOS version with processor affinity? Or is there a way to "upgrade" a thread created with forkOnIO to Bound.
Yes, forkOnOS would be possible (you can write it yourself using the primitives, in fact).
I have a thread with soft real-time requirements that cooperatively yields and uses thread local state. Right now there just doesn't seem to be any options.
Right - real-time and priorities are things that we don't do at the moment, unfortunately. Cheers, Simon
participants (6)
-
Bulat Ziganshin -
Don Stewart -
Johan Tibell -
Neal Alexander -
Simon Marlow -
Thomas DuBuisson