[erlang-questions] +swt very_low doesn't seem to avoid schedulers getting

Rickard Green <>
Thu Oct 18 20:14:42 CEST 2012

On 10/16/2012 01:08 PM, Vance Shipley wrote:
> Rickard,
> Maybe you can offer some insight into a problem I'm having.  I have
> a linked in driver which uses port level blocking with many ports.
> The driver uses driver_set_timer() to wake up in so many milliseconds
> (e.g. 10ms) to do a small amount of work in it's timeout() callback.
> What we see is that despite a low CPU usage and multiple schedulers
> often the timeout will be called quite late (e.g. 10-20ms late).

Note that the system doesn't give you any guarantees about how late the 
timeout will be triggered. It should however not be triggered before the 
timeout you have set.

I don't want to give you a figure of how late I think is reasonable and 
not reasonable. This both since it depends on a lot of things out of the 
runtime systems control, such as OS, user implemented drivers, etc, and 
also since there still exist operations in the runtime system that when 
used incautiously can monopolize a scheduler thread for a long time 
(such as a large gc).

> I have spent quite a bit of time looking at the implementation of the
> schedulers but am not sure what's going on.  I am beginning to think
> the shceduler is going off to do aux work.

Even if there are a substantial amount of aux work to do, schedulers 
will repeatedly break out from execution of aux work and check if other 
work (such as triggering timers) also need to be done.

> We've tried changing +swt without effect.  What do you think?
> On Wed, Oct 10, 2012 at 09:12:23PM +0200, Rickard Green wrote:
> }  This compaction of load onto fewer schedulers is there in order to
> }  reduce communication overhead when there aren't enough work to
> }  fully utilize all schedulers. The performance gain of this
> }  compaction depends on the hardware.

In order to know exactly what is happening you need to inspect the 
execution somehow. For example, stracing or hacking the emulator.

Rickard Green, Erlang/OTP, Ericsson AB.

More information about the erlang-questions mailing list