On Mon, 2018-09-24 at 17:23 +0200, Jan H. Schönherr wrote: > On 09/18/2018 04:40 PM, Rik van Riel wrote: > > On Fri, 2018-09-14 at 18:25 +0200, Jan H. Schönherr wrote: > > > On 09/14/2018 01:12 PM, Peter Zijlstra wrote: > > > > On Fri, Sep 07, 2018 at 11:39:47PM +0200, Jan H. Schönherr > > > > wrote: > > > > > > > > > > B) Why would I want this? > > > > > [one quoted use case from the original e-mail] > > > > What are the other use cases, and what kind of performance > > numbers do you have to show examples of workloads where > > coscheduling provides a performance benefit? > > For further use cases (still an incomplete list) let me redirect you > to the > unabridged Section B of the original e-mail: > https://lkml.org/lkml/2018/9/7/1521 > > If you want me to, I can go into more detail and make the list from > that > e-mail more complete. > > > Note, that many coscheduling use cases are not primarily about > performance. > > Sure, there are the resource contention use cases, which are barely > about > anything else. See, e.g., [1] for a survey with further pointers to > the > potential performance gains. Realizing those use cases would require > either > a user space component driving this, or another kernel component > performing > a function similar to the current auto-grouping with some more > complexity > depending on the desired level of sophistication. This extra > component is > out of my scope. But I see a coscheduler like this as an enabler for > practical applications of these kind of use cases.
Sounds like a co-scheduling system would need the following elements: 1) Identify groups of runnable tasks to run together. 2) Identify hardware that needs to be co-scheduled (for L1TF reasons, POWER7/8 restrictions, etc). 3) Pack task groups into the system in a way that allows maximum utilization by co-scheduled tasks. 4) Leave some CPU time for regular time sliced tasks. 5) In some cases, leave some CPU time idle on purpose. Step 1 would have to be reevaluated periodically, as tasks (eg. VCPUs) wake up and go to sleep. I suspect this may be much better done as its own scheduler class, instead of shoehorned into CFS. I like the idea of having some co-scheduling functionality in Linux, but I absolutely abhor the idea of making CFS even more complicated than it already is. The current code is already incredibly hard to debug or improve. Are you getting much out of CFS with your current code? It appears that your patches are fighting CFS as much as they are leveraging it, but admittedly I only looked at them briefly. -- All Rights Reversed.
signature.asc
Description: This is a digitally signed message part
