<div dir="ltr">Hi Richard,<div><br></div><div>Thank you for your help & quick reply!</div><div><br></div><div>Follow your suggestion, I do another one-week test with four versions of erlang.</div><div>V1: R16B03.origin with collapse problem</div><div>V2: R16B03.fix with my own fix patch</div><div>V3: R16B03.backport from github you provide</div><div>V4: R17B03 from <a href="http://erlang.com">erlang.com</a> </div><div><br></div><div>During the one-week test, V1 collapses twice and lasts for nearly two days.</div><div>V2 & V3 & V4 behave the same, balanced as normal.</div><div>So I will use R16B03.backport to fix my problem.</div><div>Thanks again.</div><div><br></div><div>Best Regards,</div><div>Songlu Cai</div></div><div class="gmail_extra"><br><div class="gmail_quote">2014-11-05 6:14 GMT+08:00 Rickard Green <span dir="ltr"><<a href="mailto:rickard@erlang.org" target="_blank">rickard@erlang.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Songlu Cai,<br>
<br>
Thanks for your work on this!<br>
<br>
Although it is not an error that NONEMPTY and INACTIVE flag is set at<br>
the same time it should occur rather infrequently. Assuming that this<br>
would be the case, your fix should have little effect on the behavior,<br>
so the root cause should be elsewhere. I've found a potential race<br>
when the NONEMPTY flag could end up on the run-queue of a waiting<br>
scheduler which could cause the problem you are seeing.<br>
<br>
When implementing support for balancing on scheduler utilization for<br>
OTP 17.0 I rewrote the code that set the NONEMPTY flag. This rewrite<br>
removes that potential race. I've back-ported this rewrite based on<br>
R16B03-1. It can be found in the<br>
rickard/R16B03-1/load_balance/OTP-11385 branch<br>
<<a href="https://github.com/rickard-green/otp/tree/rickard/R16B03-1/load_balance/OTP-11385" target="_blank">https://github.com/rickard-green/otp/tree/rickard/R16B03-1/load_balance/OTP-11385</a>><br>
of my github repo <<a href="https://github.com/rickard-green/otp.git" target="_blank">https://github.com/rickard-green/otp.git</a>>. Please<br>
try it out and see if it solves your problem (use the same<br>
configuration as before).<br>
<br>
Something similar to your fix should perhaps in the end be introduced<br>
anyway (one also has to check the SUSPENDED flag though), since there<br>
are no good reason to prevent the activation just because the<br>
run-queue happen to be non-empty. It would, however, be good to see<br>
that the root issue has been fixed first before introducing this.<br>
<br>
Regards,<br>
Rickard Green, Erlang/OTP, Ericsson AB<br>
<div><div class="h5"><br>
On Mon, Nov 3, 2014 at 4:18 PM, songlu cai <<a href="mailto:caisonglu@gmail.com">caisonglu@gmail.com</a>> wrote:<br>
> Hi Scott,<br>
><br>
> Last week I fix the bug in a simple way, then I run the fixed-version<br>
> compared with the old unbalanced-version.<br>
> The two nodes are with same pressure &  timeline.<br>
> The unbalanced(collapsed) state comes up several times on the old version,<br>
> but never show up on the fixed version.<br>
> The pressure spreads averagely among 24 schedulers on the fixed version<br>
> (especially when with high pressure).<br>
> In fact, the fixed version is with higher pressure when old version runs<br>
> into the unbalanced state.<br>
> Because the old version is only with 4 schedulers, and easily gets to the<br>
> bottleneck,  its cpu is 400%, at the same time, fixed version is with cpu<br>
> 1200%.<br>
> So I can be sure that the root cause of unbalanced scheduler (scheduler<br>
> collapse) is "using out of date active_no_runq", just as analyzed before.<br>
><br>
> I just modify the chk_wake_sched function, code diff as below:<br>
><br>
> Index: emulator/beam/erl_process.c<br>
> ===================================================================<br>
> --- emulator/beam/erl_process.c (revision 298281)<br>
> +++ emulator/beam/erl_process.c (working copy)<br>
> @@ -2694,6 +2694,16 @@<br>
>         return 0;<br>
>      wrq = ERTS_RUNQ_IX(ix);<br>
>      flags = ERTS_RUNQ_FLGS_GET(wrq);<br>
> +<br>
> +    if ( activate &&<br>
> +       (flags & ERTS_RUNQ_FLG_NONEMPTY)  &&<br>
> +       (flags & ERTS_RUNQ_FLG_INACTIVE)) {<br>
> +       if (try_inc_no_active_runqs(ix+1))<br>
> +               (void) ERTS_RUNQ_FLGS_UNSET(wrq, ERTS_RUNQ_FLG_INACTIVE);<br>
> +       wake_scheduler(wrq, 0);<br>
> +       return 1;<br>
> +    }<br>
> +<br>
>      if (!(flags & (ERTS_RUNQ_FLG_SUSPENDED|ERTS_RUNQ_FLG_NONEMPTY))) {<br>
>         if (activate) {<br>
>             if (try_inc_no_active_runqs(ix+1))<br>
><br>
> It saves the scheduler from the weird state. It is not a perfect fix, but an<br>
> effective one.<br>
> Scott, would you please apply this patch to R16B03 and run your test case<br>
> again?<br>
> Thank you very much and waiting for your reply.<br>
> And I will run it for a week to ensure that we do fix the problem.<br>
><br>
> Best Regards,<br>
> Songlu Cai<br>
><br>
> 2014-10-31 10:55 GMT+08:00 songlu cai <<a href="mailto:caisonglu@gmail.com">caisonglu@gmail.com</a>>:<br>
>><br>
>> Hi Scott,<br>
>><br>
>><br>
>><br>
>> Thanks for your attention & quick reply.<br>
>><br>
>> It seems that quite a few people suffer from this problem.<br>
>><br>
>><br>
>><br>
>> Scott>The best workaround is to use "+scl false" and "+sfwi" with a value<br>
>> of 500 or a bit smaller<br>
>><br>
>> 1, we set +sfwi 500<br>
>><br>
>> 2,at first, we set +scl false, but it causes unbalanced runq length among<br>
>> all runqs on R16B03, then we set +scl true (by default), so +scl false is<br>
>> not a safe choice on R16B03<br>
>><br>
>><br>
>><br>
>> Our test cmdline:<br>
>><br>
>> /home/Xxx/erts-5.10.4/bin/beam.smp -zdbbl 8192 -sbt db -sbwt very_short<br>
>> -swt low -sfwi 500 -MBmmsbc 100 -MHmmsbc 100 -MBmmmbc 100 -MHmmmbc 100<br>
>> -MMscs 20480 -MBsmbcs 10240 -MHsbct 2048 -W w -e 50000 -Q 1000000 -hmbs<br>
>> 46422 -hms 2586 -P 1000000 -A 16 -K true -d -Bi -sct<br>
>> L23T0C0P0N0:L22T1C1P0N0:L21T2C2P0N0:L20T3C3P0N0:L19T4C4P0N0:L18T5C5P0N0:L17T6C0P1N1:L16T7C1P1N1:L15T8C2P1N1:L14T9C3P1N1:L13T10C4P1N1:L12T11C5P1N1:L11T12C0P0N0:L10T13C1P0N0:L9T14C2P0N0:L8T15C3P0N0:L7T16C4P0N0:L6T17C5P0N0:L5T18C0P1N1:L4T19C1P1N1:L3T20C2P1N1:L2T21C3P1N1:L1T22C4P1N1:L0T23C5P1N1<br>
>> -swct medium -- -root /home/Xxx/dir -progname Xxx -- -home /root -- -boot<br>
>> /home/Xxx/dir -mode interactive -config /home/Xxx/sys.config -shutdown_time<br>
>> 30000 -heart -setcookie Xxx -name proxy@Xxx – console<br>
>><br>
>><br>
>><br>
>> And , apart from everything else, INACTIVE|NONEMPTY is not a normal state<br>
>> of runq flag.<br>
>><br>
>> Next few days, I will fix the not-yet-be-sure bug in my way based on<br>
>> R16B03 and run the test cases again.<br>
>><br>
>><br>
>> Best Regards,<br>
>><br>
>> Songlu Cai<br>
>><br>
>><br>
>> 2014-10-30 15:53 GMT+08:00 Scott Lystig Fritchie <<a href="mailto:fritchie@snookles.com">fritchie@snookles.com</a>>:<br>
>>><br>
>>> songlu cai <<a href="mailto:caisonglu@gmail.com">caisonglu@gmail.com</a>> wrote:<br>
>>><br>
>>> slc> How to fix:<br>
>>><br>
>>> slc> [...]<br>
>>><br>
>>> slc> 3, Or Another Way?<br>
>>><br>
>>> Wow, that's quite a diagnosis.  I'm not a good judge of the race<br>
>>> condition that you've found or your fix.  I can provide some context,<br>
>>> however, in case that you weren't aware of it.  It might help to create<br>
>>> a Real, Final, 100% Correct Fix ... something which does not exist right<br>
>>> now.<br>
>>><br>
>>> The best workaround is to use "+scl false" and "+sfwi" with a value of<br>
>>> 500 or a bit smaller.  See the discussion last month about it,<br>
>>><br>
>>><br>
>>> <a href="http://erlang.org/pipermail/erlang-questions/2014-September/081017.html" target="_blank">http://erlang.org/pipermail/erlang-questions/2014-September/081017.html</a><br>
>>><br>
>>> My colleague Joe Blomstedt wrote a demo program that can cause scheduler<br>
>>> collapse to happen pretty quickly.  It might be useful for judging how<br>
>>> well any fix works ... at Basho we had a terrible time trying to<br>
>>> reproduce this bug before Joe found a semi-reliable trigger.<br>
>>><br>
>>>     <a href="https://github.com/basho/nifwait" target="_blank">https://github.com/basho/nifwait</a><br>
>>><br>
>>> It is discussed in this email thread (which is broken across two URLs,<br>
>>> sorry).<br>
>>><br>
>>>     <a href="http://erlang.org/pipermail/erlang-questions/2012-October/069503.html" target="_blank">http://erlang.org/pipermail/erlang-questions/2012-October/069503.html</a><br>
>>>         (first message only, I don't know why)<br>
>>>     <a href="http://erlang.org/pipermail/erlang-questions/2012-October/069585.html" target="_blank">http://erlang.org/pipermail/erlang-questions/2012-October/069585.html</a><br>
>>>         (the rest of the thread)<br>
>>><br>
>>> If your analysis is correct ... then hopefully this can lead quickly to<br>
>>> a Real, Final, 100% Correct Fix.  I'm tired of diagnosing systems that<br>
>>> suffer scheduler collapse and then discover that the customer forgot to<br>
>>> add the magic +sfwi and +scl flags in their runtime configuration to<br>
>>> work around that !@#$! bug.<br>
>>><br>
>>> -Scott<br>
>><br>
>><br>
><br>
><br>
</div></div>> _______________________________________________<br>
> erlang-questions mailing list<br>
> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
><br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Rickard Green, Erlang/OTP, Ericsson AB<br>
</font></span></blockquote></div><br></div>