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.
Regards,
Tvrtko
