On Tue, 20 Jan 2026 09:51:48 +0000 Tvrtko Ursulin wrote:
On 15/01/2026 23:39, Danilo Krummrich wrote:
> On Thu Jan 15, 2026 at 2:00 PM CET, Tvrtko Ursulin wrote:
8><
>> Okay but I am sure you know there are memory barriers, RCU, SPSC queue,
>> completions, worker management, and at least two locks, and everything
>> is interdependent.
>
> I am, and I couldn't describe the maintainance burden of the scheduler any
> better. :)
>
>> This series at least removes a bunch of code without making things more
>> complicated and so can be a good base for further rework. If you suggest to
>> hold it until all of the above is resolved it will be a few more years
easily.
>
> Let me explain a bit where I'm coming from:
>
> From a maintainer perspective - without saying that things are either black or
> white - I'm assessing contributors and contributions on whether the intention
is
> to improve the infrastructure in terms of design and maintainability or
whether
> the main intention is to "just" get a certain feature merged.
>
> While both are valuable contributions that are appreciated, contributions that
> have a tendency into the latter direction, have to be seen with more
sceptisism.
>
> Especially when the code base already has known design issues, bulding features
> on top is very dangerous. Not necessarily because the resulting code might be
> wrong or because of regressions, etc. But because it most likely increases the
> difficulty resolving the existing issues -- in the worst case leading to a
dead
> end.
>
> Having that said, I am not saying that you "just" try to get your feature merged
> no matter what. Quite the opposite, I very much appreciate your contributions
to
> the scheduler and recognize the cleanup work you are doing.
>
> However, for this series I require you to acknowledge that, even if correct,
> some of this code introduces additional workarounds due to existing design
> issues, locking and synchronization subtleties that should be solved in better
> ways.
>
> I have no objections going ahead with this series if we are on the same page
> regarding this and you are willing to also help out fixing those underlying
> design issues, locking and synchronization quirks, etc. subsequently.
>
> But if you are more leaning in the direction of "I don't see an issue overall,
> the code is correct!" I do have concerns.
>
> Improving the situation with the scheduler is the fundamental reason why Philipp
> and me were stepping up as maintainers, Philipp being more of the active part
> (doing a great job) and me working more in the background, helping and
mentoring
> him.
>
> Believe me when I say that we want this to move forward, but we also have to
> ensure that we are not making a step into the direction of increasing the
> difficulty to solve the underlying issues.
>
> So, again, if we are on the same page with this, no objections from my side.
I thought it would have been obvious by now that I am trying to improve
and fix things across the board. I even mentioned I had attempted a more
ambitious rewrite already, which hit some stumbling blocks, so I settled
for this smaller step first.
I am also glad to hear there is desire to attempt more significant
refactors. Because in the past I was a bit concerned with a little bit
of "it's scary don't touch it" messaging.
So yes, I do plan to stick around to keep fixing and improving things.
After FIFO and RR are cut in the subsequent 12/28, you have a couple of options
1, forget priority once for all given vruntime, or
2, prio will not change once entity is created, or
3, move prio to entity->stats
