On Wed, Jun 19, 2024 at 7:35 PM Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: [...] > Just for the record, the scheduler people and myself spent a lot of time > to help to get intrusive features like UMCG into mainline, but the > efforts were dropped by the submitters for no reason. Short time after > that sched_ext came around. Hi Thomas, I'm sorry I missed this callout re: UMCG last week. The efforts were not dropped on our side, I assure you. For example, I posted this last year: https://lore.kernel.org/lkml/CAPNVh5eNEBu+gcex9pAej-_YN3zMKkG+rruXhopqS6EaG-izVQ@xxxxxxxxxxxxxx/T/ and I got no indication re: how I should proceed. There were several earlier LKML posts that similarly did not result in any actionable feedback. Based on this clear (maybe just perceived? if so, I apologize) lack of interest in making UMCG ready for upstream/mainline, we've decided to wait for sched_ext to get merged; sched_ext already existed at the time, e.g. https://lore.kernel.org/lkml/20221130082313.3241517-1-tj@xxxxxxxxxx/. I believe that sched_ext is flexible enough that, once merged, it will allow us to build UMCG-like per-process schedulers on top of it, so I see no reason in pushing both UMCG and sched_ext, given the difficulty of getting anything merged. If I had to choose between UMCG and sched_ext getting upstream (and I do not see both UMCG _and_ sched_ext getting merged together any time soon), I'd choose sched_ext, because it naturally opens up more opportunities to tailor scheduling to different workloads. Again, I appreciate the initial help and feedback you and Peter provided re: UMCG; but then things stalled and I was not getting any clear indication how to proceed; and given that UMCG can be built on top of sched_ext (or ghost), and a clear (or perhaps also just perceived) preference by sched maintainers to avoid competing solutions, I now believe that sched_ext should be merged first. Thanks, Peter [...]
