<div dir="ltr"><div>I think you somewhat misunderstood Ron's comment on "same". Same means that they are progressing the same task. For example, you have a large composite task which  is made up of 100 small chunks, and then you start these 100 chunks of work in parallel. If you are fair, then what you will see is that 0%, 0% ... and suddenly 100% when all of them are completed (assuming total fairness). While in case of non-fair, you will see progress that few chunks done, yet a few more done, etc.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Robert Engels <<a href="mailto:robaho@icloud.com">robaho@icloud.com</a>> ezt írta (időpont: 2024. júl. 3., Sze, 18:44):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;">I don't think that is correct - but I could be wrong.<div><br></div><div>With platform threads the min and max latency in a completely cpu bound scenario should be very close the the average with a completely fair scheduler (when all tasks/threads are submitted at the same time).</div><div><br></div><div>Without timesharing, the average will be the same, but the min and max latencies will be far off the average - as the tasks submitted first complete very quickly, and the tasks submitted at the end take a very long time because they need to have all of the tasks before them complete.</div><div><br></div><div>In regards to the the “enough cpus” comment, I only meant that if there are enough cpus and a “somewhat” balanced workload, it is unlikely that all of the cpu bounds tasks could consume all of the carrier threads given a random distribution. If you have more active tasks than cpus and the majority of the tasks are cpu bound, the IO tasks are going to suffer in a non-timesliced scenario - they will be stalled waiting for a carrier thread - even though the amount of cpu they need will be very small.</div><div><br></div><div>This has a lot of info on the subject <a href="https://docs.kernel.org/scheduler/sched-design-CFS.html" target="_blank">https://docs.kernel.org/scheduler/sched-design-CFS.html</a> including:</div><div><br></div><div><span style="color:rgb(62,67,73);font-family:serif;font-size:medium;background-color:rgb(255,255,255)">On real hardware, we can run only a single task at once, so we have to introduce the concept of “virtual runtime.” The virtual runtime of a task specifies when its next timeslice would start execution on the ideal multi-tasking CPU described above. In practice, the virtual runtime of a task is its actual runtime normalized to the total number of running tasks.</span></div><div><br></div><div><div>I recommend this  <a href="https://opensource.com/article/19/2/fair-scheduling-linux" target="_blank">https://opensource.com/article/19/2/fair-scheduling-linux</a> for an in-depth discussion on how the dynamic timeslices are computed.</div><div><br></div><div>The linux scheduler relies on timeslicing in order to have a “fair” system. I think most Java “server” type applications strive for fairness as well - i.e. long tail latencies in anything are VERY bad (thus the constant fight against long GC pauses - better to amortize those for consistency).</div><div><br></div></div></div></blockquote></div></div>