Date: Thu, 20 Jun 2024 09:35:20 -1000
From: Tejun Heo <tj@...nel.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>, mingo@...hat.com,
	peterz@...radead.org, juri.lelli@...hat.com,
	vincent.guittot@...aro.org, dietmar.eggemann@....com,
	rostedt@...dmis.org, bsegall@...gle.com, mgorman@...e.de,
	bristot@...hat.com, vschneid@...hat.com, ast@...nel.org,
	daniel@...earbox.net, andrii@...nel.org, martin.lau@...nel.org,
	joshdon@...gle.com, brho@...gle.com, pjt@...gle.com,
	derkling@...gle.com, haoluo@...gle.com, dvernet@...a.com,
	dschatzberg@...a.com, dskarlat@...cmu.edu, riel@...riel.com,
	changwoo@...lia.com, himadrics@...ia.fr, memxor@...il.com,
	andrea.righi@...onical.com, joel@...lfernandes.org,
	linux-kernel@...r.kernel.org, bpf@...r.kernel.org,
	kernel-team@...a.com
Subject: Re: [PATCHSET v6] sched: Implement BPF extensible scheduler class

Hello, Thomas.

On Thu, Jun 20, 2024 at 04:35:08AM +0200, Thomas Gleixner wrote:
...
> There have been voiced a lot of technical arguments, which never got
> addressed and at some point people gave up due to being ignored.

More on the in-person discussion later, but can you please point to the many
technical arguments that have been ignored? I addressed all the review
points that PeterZ raised on the first RFC patchset and responded to most of
the arguments that were raised. There haven’t been any technical feedbacks
since then. If there are things that I missed, please point them out, I'd be
happy to respond.

> When I sat there in Richmond with the sched_ext people I gave them very
> deep technical feedback especially on the way how they integrate it:
> 
>   Sprinkle hooks and callbacks all over the place until it works by some
>   definition of works.

I would characterize that part of the discussion more nebulous than deep.
You cited a really high number for where SCX is hooking into the scheduler
core and then made wide-ranging suggestions including refactoring all the
schedulers, which seemed vague and out of scope. I tried to probe and we
didn't get anywhere concrete, which is fine. It's difficult to hash out
details in such settings.

> That's perfectly fine for a PoC, but not for something which gets merged
> into the core of an OS. I clearly asked them to refactor the existing
> code so that these warts go away and everything is contained into the
> scheduler classes and at the very end sched_ext falls into place. That's
> a basic engineering principle as far as I know.
> 
> They nodded, ignored my feedback and just continued to pursue their way.

However, this is not true. During the discussion, I asked you multiple times
to review the patches and point out the parts that are problematic so that
they can be addressed and the discussion can become more concrete. You
promised you would but didn't.

This patch series has been up in one form or another for almost two years.
It took forcing the discussion in Richmond to get any responses from you and
Peter, and what we got wasn't feedback on the patches, but verbal
suggestions about SCX itself, and suggestions that X for Y would help us.
When we attempted to follow up with you afterwards, we got no responses.

Now that Linus said he would pull it, there all of a sudden are discussions
about the code. It seems likely that we wouldn't have that without Linus'
email last week. The raised issues seem resolvable and mostly stem from
trying to minimize changes to sched core. I don’t see a reason why this
would warrant yet another delay. Why can’t we work it out in tree like any
other problem?

Thanks.

-- 
tejun

Powered by blists - more mailing lists