<div dir="ltr"><font face="monospace">Interesting, thanks Rik. I assumed that couldn't be correct, since it would result in lower priority tasks receiving a slice less than the </font><span style="font-family:monospace">sysctl_sched_min_granularity - which I assumed CFS explicitly aims to prevent.</span><div><span style="font-family:monospace"><br></span></div><div><span style="font-family:monospace">Thanks for taking a look.</span></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 3, 2020 at 1:51 AM Valdis Klētnieks <<a href="mailto:valdis.kletnieks@vt.edu" target="_blank">valdis.kletnieks@vt.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, 02 Apr 2020 22:10:11 -0400, Evan T Mesterhazy said:<br>
<br>
> I ran a test by starting five busy processes with a nice level of -10.<br>
> Next, I launched ~40 busy processes with a nice level of 0 (all procs were<br>
> set to use the same CPU). I expected CFS to expand the period and assign<br>
> each process a slice equal to the min granularity. However, the 5 processes<br>
> with nice = -10 still used considerably more CPU than the other processes.<br>
<br>
Well, it's *expected* that if you set nice = -10 they'll get more CPU.<br>
<br>
Do you have any evidence that CFS *didn't* give the nice==0 processes a<br>
min_granularity slide once in a while?<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr">Evan Mesterhazy<div><a href="mailto:etm2131@columbia.edu" target="_blank">etm2131@columbia.edu</a></div></div></div></div></div>