<div><div><div><div dir="auto">Thanks Rickard.</div><div dir="auto"><br></div><div dir="auto">@Jonas: did the PR2093 help in your case?</div><div dir="auto"><br></div><div dir="auto">/Frank</div><br></div></div></div><div><div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2019-01-15 23:11, Jesse Stimpson wrote:<br>
> Behavior of the schedulers appears to have the same issue with 2093 patch.<br>
> <br>
> But I did notice something new in the msacc output. There is a very <br>
> brief period, at approx the same time as the normal schedulers usage <br>
> spikes, where all the dirty cpu schedulers have a significant sleep <br>
> time. I've included timestamped excerpts below, starting with the <br>
> increase in dirty cpu sleep, and ending with a "steady state" utilization.<br>
> <br>
<br>
We just released OTP-21.2.3 containing PR-2093.<br>
<br>
I don't think PR-2093 cause the spikes. This change does not affect how <br>
work is moved between normal and dirty schedulers, only prevents the <br>
"loss" of dirty schedulers.<br>
<br>
If a process is scheduled on a dirty scheduler it wont make progress <br>
until it has executed on a dirty scheduler and vice versa (for normal <br>
schedulers). This is the same both before and after PR-2093. Since dirty <br>
schedulers aren't "lost" after PR-2093 progress of such processes will <br>
happen earlier which of course change the behavior, but that is due to <br>
the work load.<br>
<br>
Regards,<br>
Rickard<br>
</blockquote></div></div>
</div>
</div>