[erlang-questions] Why system_flag(scheduler_bind_type) is deprecated?

Angel J. Alvarez Miguel clist@REDACTED
Fri Jan 4 12:54:46 CET 2013


hi

I look a this :

"...since we do not want to change this configuration in runtime..."

This sounds a bit limiting

Current platforms can (and will) shutdown CPU cores in response to power management policies 
and erlang deamonized software must adapt to this changes without needing a restart.

While it seems at first an unprobable scenario right now, on server side it really sounds good when 
you run erlang on laptop/mobile platforms.

Even some virtualization products are planin to use hot-plug facilities to make resource management easier on current
platforms so its not really crazy today to think that cpu cores will come and leave at unexpected times on tipical cloud scenarios.

IMHO the ability to sense this on user code and facilities to control or alter the scheduler behaviour will be more important 
in the near future , thus having to restart the entire VM for this seems overkill and a backward movement from the current setup.

I have recently experimiented this during the summer case when i unplug my laptop my power management script 
shut down half of the cores when battery starts to run out and lowers de cpu frecuency and erlang responded 
on stderrr something about scheduler failure trying to bind to the dead cores, then i managed to make some tests trying to
 monitor this from erlang code and to put schedulers offline until cores reapear again.

Even i can depict scenarios where depending on licensing feaures application code can control the amount of paralelism 
the VM will exhibit by tweaking schedulers affinity or just shutting them down to limit to the cores licensed...

You should think about this even if you plan to make other improvements

Regards, Angel

On Jueves, 27 de Diciembre de 2012 00:45:05 Rickard Green escribió:
> On Dec 26, 2012, at 5:21 PM, Max Lapshin <max.lapshin@REDACTED> wrote:
> > Why system_flag(scheduler_bind_type, How) is deprecated in favor of +sbt
> > flag?
> > 
> > This sbt flag is different when I have to launch via escript or via erl
> > and this is why it is less convenient than using system_flag call.
> > 
> > Also system_flag call can be called according to some system
> > configuration file and sbt needs full restart.
> 
> Both the 'cpu_topology' and the 'scheduler_bind_type' arguments of the
> system_flag/2 BIF are deprecated and will be removed since we do not want
> to change this configuration in runtime. With the support for this we got
> today the runtime configuration change isn't that problematic, but it
> prevents future planned improvements from being implemented.
> 
> Regards,
> Rickard Green, Erlang/OTP, Ericsson AB
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions



More information about the erlang-questions mailing list