Re: [PATCHSET v6] sched: Implement BPF extensible scheduler class

[Peter Oskolkov]

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


[...]