You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In a concurrent program we want to drive the CPU utilization as high as possible and task latencies as low as possible. If there are tasks that are on the CPU for long time, they can cause latency issues. Usually Haskell threads yield on allocations, but if there are tight loops without allocation or FFI calls, threads can run for longer times.
To study latency behavior in concurrent programs we want to monitor the thread runqueue length. If all the threads are blocked for resources for long durations keeping runq empty and CPU idle, that may indicate an issue. If the runq is idle and busy in bursts that may indicate a problem.
To drive latencies lower, IO bound tasks that may run for short durations on CPU and then block for IO should be given priority compared to longer CPU bound tasks that could run while the IO bound tasks are blocked. But not sure if there is a simple way to achieve roughly something like this. Keeping the time slice lower is the only simple way. But we can at least measure if this is a problem.
The text was updated successfully, but these errors were encountered:
In a concurrent program we want to drive the CPU utilization as high as possible and task latencies as low as possible. If there are tasks that are on the CPU for long time, they can cause latency issues. Usually Haskell threads yield on allocations, but if there are tight loops without allocation or FFI calls, threads can run for longer times.
To study latency behavior in concurrent programs we want to monitor the thread runqueue length. If all the threads are blocked for resources for long durations keeping runq empty and CPU idle, that may indicate an issue. If the runq is idle and busy in bursts that may indicate a problem.
To drive latencies lower, IO bound tasks that may run for short durations on CPU and then block for IO should be given priority compared to longer CPU bound tasks that could run while the IO bound tasks are blocked. But not sure if there is a simple way to achieve roughly something like this. Keeping the time slice lower is the only simple way. But we can at least measure if this is a problem.
The text was updated successfully, but these errors were encountered: