The schedulers going out of work should spin for a while before parking themselves with back-off (e.g. pause/sleep for an increasing amount of time on each spin). That should help limit an expensive call to wake up a parked thread (currently: mutex lock + condition variable signal) just to see the scheduler park itself right away if it failed to steal a runnable fiber(rince and repeat).
There should be a couple limits:
how many schedulers are allowed to spin, to avoid burning CPUs pointlessly + potential thundering herd issue with too many schedulers trying to steal from the same scheduler at the same time. Go for example limits the number of spinning schedulers to half the number of running schedulers —what if there's only one running scheduler?
how long a scheduler shall spin, so we don't keep a thread alive for no reason (impact on CPU/battery).
ysbaddaden
commented
7 months ago
The schedulers going out of work should spin for a while before parking themselves with back-off (e.g. pause/sleep for an increasing amount of time on each spin). That should help limit an expensive call to wake up a parked thread (currently: mutex lock + condition variable signal) just to see the scheduler park itself right away if it failed to steal a runnable fiber(rince and repeat).
There should be a couple limits:
how many schedulers are allowed to spin, to avoid burning CPUs pointlessly + potential thundering herd issue with too many schedulers trying to steal from the same scheduler at the same time. Go for example limits the number of spinning schedulers to half the number of running schedulers —what if there's only one running scheduler?
how long a scheduler shall spin, so we don't keep a thread alive for no reason (impact on CPU/battery).