On 8/18/26 15:06, Lorenzo Stoakes (ARM) wrote:
> (I'll reply to the rest of this later)
>
> On Mon, Aug 17, 2026 at 02:38:44PM +0100, Kiryl Shutsemau wrote:
>> David and I talked about this at LSF/MM. I can give it a try if it fits
>> your idea of "feature freeze" -- and if it doesn't collide with the series
>> you have in flight, in which case I'd rather go after yours than around it.
>
> Whether intended or not you sound rather like you are trying to override me
> in favour of my co-maintainer here and it's... not helpful.
I think Kiryl tried to say that we discussed at LSF/MM which areas of MM scream
for an improvement, and we discussed that khugepaged is just horrible code.
I think we all agree that there is a lot of room for improvement, but the big
question is:
(a) When does it stop being a cleanup and is a new feature in disguise that
makes the code more complicated and even harder to maintain.
(b) Can it just naturally be made looking like a cleanup.
Ideally, we'd get b), in small, nice-to-review chunks that incrementally improve
the code without inflating it heavily or moving everything around.
The current locking is nasty, so anything that moves us one step closer into
something that is not only simpler but also more scalable is nice. I am a bit
concerned with the churn in the series as is.
After this series, mm/collapse.c itself is way larger than just mm/khugepaged.c
originally, which raises some eyebrows.
We should also be aware that people are proposing file/shmem mTHP collapse, so
ideally what we refactor would naturally unify some of these code paths.
I am wondering whether shmem mTHP collapse should come first. (I'm hoping that
shmem mTHP collapse can unify some of the anon+file collapse code in a nice way,
to similarly just look like a cleanup while enabling a new scenario. Which is
really what I am hoping for because the current code is A MESS with weirdly
named functions all over the place. I hope it can be unified somehow ... and
that needs some proper thought)
>
> David and I co-maintain THP together, are in constant communication, and
> have a great working relationship :)
Yes! :)
>
> IOW - if one of us states a position on the sub(sub?)system - then take
> that to be the actual position.
>
> I have poured what must be hundreds of hours now into THP maintainership -
> it's by far my biggest workload on the maintenance front, by far the most
> painful and by far the most thankless.
>
> I do it because I care about mm a great deal and am, frankly, driven by a
> desire to see THP turn from a flaming trash pile of a code base with
> confusing semantics and many, many broken parts into something that serves
> the community's needs with far less maintenance burden.
>
> Looking over your series it seems some of the patches works in this
> direction (great!), but much else of it fundamentally changes key
> behaviour.
Agreed, I think we really should unify+cleanup the existing code first before
doing more drastic changes.
Having a series that throws all of khugepaged.c into a mixer and pours something
new into collapse.c is ... concerning :)
But I am sure there is a way to incrementally improve the code? At least that's
what I hope.
>
> So it's just a question of deferring the latter until we get to a sane
> point with the former.
Thanks Lorenzo.
--
Cheers,
David
