<div dir="ltr"><div class="gmail_extra"><div>The short answer:  'man 7 sched'</div><div><br></div><div>Thanks I read this and I think I might still be confused. I am using cgroups</div><div>and have cpu.cfs_quota_us configured as 2300000 and cpu.cfs_period_us</div><div>configured as 100000 for 3 different cgroups of, all of these I assume equates</div><div>69 cpus along with a couple of other cgroups with cpu.cfs_quota_us configured</div><div>on a 80 cpu machine which is why I made my original guess.</div><div><br></div><div>The first question is, of course: "Did you see any actual evidence of kernel</div><div>threads being starved?"</div><div><br></div><div>I have a couple of very similar machines with similar workloads and observed</div><div>the below type of messages in dmesg on several of them:</div><div><br></div><div>rcu_sched detected stalls on CPUs</div><div>Sending NMI from CPU 43 to CPUs 14</div><div>watchdog: BUG: soft lockup - CPU#26 stuck for 22s [migration/54:335]</div><div>ixgbe 0000:19:00.1 eno2: initiating reset due to tx timeout</div><div><br></div><div>Which is why I have this hypothesis.</div><div><br></div><div>I am still unclear if the cgroup group controller makes guarantees such that</div><div>tasks in the cgroup cannot be preempted even if a kernel thread requires cpu</div><div>time.</div><div><br></div><div>Thanks for your time!</div><div><br></div><div><div class="gmail_signature"><div dir="ltr">Abejide Ayodele<br><span style="color:rgb(85,85,85);font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:15px;line-height:22px">It always seems impossible until it's done. --Nelson Mandela</span></div></div></div></div></div>