[erlang-questions] About Erlang SMP scheduler
"Siyao Zheng(郑思遥)"
zhengsyao@REDACTED
Fri Apr 27 15:58:32 CEST 2012
Hi,
schedule(), in which check_balance() is only called.
In schedule(), when check_balance_reds reaches zero, scheduler decides to "check_balance". But later in schedule(), when scheduler finds run queue being empty, it will try to steal task from other schedulers (by calling try_steal_task()), which is also a load balance mechanism. I'm just wondering what the purpose of check_balance().
Cheers
Siyao
On Apr 27, 2012, at 9:40 PM, Zabrane Mickael wrote:
> Hi Siyao,
>
> Which "check_balance" you've commented out?
>
> Here is what I found so far:
>
> $ find /otp_src_R15B01 -type f | xargs grep check_balance | grep -v matches
> /opt/otp_src_R15B01/erts/emulator/beam/erl_process.c: int forced_check_balance;
> /opt/otp_src_R15B01/erts/emulator/beam/erl_process.c:check_balance(ErtsRunQueue *c_rq)
> /opt/otp_src_R15B01/erts/emulator/beam/erl_process.c:# error check_balance() assumes ERTS_MAX_PROCESS < (1 << 27)
> /opt/otp_src_R15B01/erts/emulator/beam/erl_process.c: c_rq->check_balance_reds = INT_MAX;
> /opt/otp_src_R15B01/erts/emulator/beam/erl_process.c: c_rq->check_balance_reds = INT_MAX;
> /opt/otp_src_R15B01/erts/emulator/beam/erl_process.c: rq->check_balance_reds = ERTS_RUNQ_CALL_CHECK_BALANCE_REDS;
> /opt/otp_src_R15B01/erts/emulator/beam/erl_process.c: * check_balance() is never called in more threads
> /opt/otp_src_R15B01/erts/emulator/beam/erl_process.c: forced = balance_info.forced_check_balance;
> /opt/otp_src_R15B01/erts/emulator/beam/erl_process.c: balance_info.forced_check_balance = 0;
> /opt/otp_src_R15B01/erts/emulator/beam/erl_process.c: c_rq->check_balance_reds = INT_MAX;
> /opt/otp_src_R15B01/erts/emulator/beam/erl_process.c: rq->check_balance_reds = INT_MAX;
> /opt/otp_src_R15B01/erts/emulator/beam/erl_process.c: rq->check_balance_reds = ERTS_RUNQ_CALL_CHECK_BALANCE_REDS;
> /opt/otp_src_R15B01/erts/emulator/beam/erl_process.c: rq->check_balance_reds = ERTS_RUNQ_CALL_CHECK_BALANCE_REDS;
> /opt/otp_src_R15B01/erts/emulator/beam/erl_process.c: balance_info.forced_check_balance = 0;
> /opt/otp_src_R15B01/erts/emulator/beam/erl_process.c: (RQ)->check_balance_reds = ERTS_RUNQ_CALL_CHECK_BALANCE_REDS; \
> /opt/otp_src_R15B01/erts/emulator/beam/erl_process.c: balance_info.forced_check_balance = 1;
> /opt/otp_src_R15B01/erts/emulator/beam/erl_process.c: ERTS_RUNQ_IX(0)->check_balance_reds = 0;
> /opt/otp_src_R15B01/erts/emulator/beam/erl_process.c: if (rq->check_balance_reds <= 0)
> /opt/otp_src_R15B01/erts/emulator/beam/erl_process.c: check_balance(rq);
> /opt/otp_src_R15B01/erts/emulator/beam/erl_process.h: int check_balance_reds;
> /opt/otp_src_R15B01/erts/emulator/beam/erl_process.h: (RQ)->check_balance_reds -= (REDS); \
> /opt/otp_src_R15B01/erts/emulator/beam/erl_process.h: (RQ)->check_balance_reds -= (REDS);
> [...]
>
> For OTP Team: is this dangerous ?
>
> Regards,
> Zabrane
>
>
> On Apr 27, 2012, at 1:23 PM, Siyao Zheng(郑思遥) wrote:
>
>> Hi,
>>
>> In SMP version of Erlang, every scheduler periodically call "check_balance()" to check load balance among all schedulers, then it might migrate some processes to balance load, or shut down some schedulers with low load. Does anyone know why scheduler should do this? check_balance() is quite a big one, and it has to lock every run queue when it checks the run queue. I think it's quite a big cost here. The work stealing at each schedule step afterwards actually does work load balance very well. Actually after I comment out the check_balance() step and run BigBang and Hackbench benchmarks, they are really faster!
>>
>> So, I wonder what is the purpose of check_balance() step here, if it is related to scalability on many core processors or something, and if there is any other benchmark I can run to prove its usefulness.
>>
>> Cheers!
>>
>> Siyao
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>
>
More information about the erlang-questions
mailing list