[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAJuCfpEbmc_hhom3A6_V2wJB1rxNHMfW1ebg2TnnMRfE8asahg@mail.gmail.com>
Date: Sun, 25 Jan 2026 22:09:50 -0800
From: Suren Baghdasaryan <surenb@...gle.com>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>, David Hildenbrand <david@...nel.org>,
"Liam R . Howlett" <Liam.Howlett@...cle.com>, Vlastimil Babka <vbabka@...e.cz>,
Mike Rapoport <rppt@...nel.org>, Michal Hocko <mhocko@...e.com>, Shakeel Butt <shakeel.butt@...ux.dev>,
Jann Horn <jannh@...gle.com>, linux-mm@...ck.org, linux-kernel@...r.kernel.org,
linux-rt-devel@...ts.linux.dev, Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>, Will Deacon <will@...nel.org>, Boqun Feng <boqun.feng@...il.com>,
Waiman Long <longman@...hat.com>, Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Clark Williams <clrkwllms@...nel.org>, Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH RESEND v3 07/10] mm/vma: introduce helper struct + thread
through exclusive lock fns
On Sat, Jan 24, 2026 at 12:54 AM Lorenzo Stoakes
<lorenzo.stoakes@...cle.com> wrote:
>
> On Fri, Jan 23, 2026 at 02:07:43PM -0800, Suren Baghdasaryan wrote:
> >
> > Sorry, I didn't realize I was causing that much trouble and I
> > understand your frustration.
> > From your reply, it sounds like you made enough changes to the patch
> > that my concern might already be obsolete. I'll review the new
> > submission on Sunday and will provide my feedback.
> > Thanks,
> > Suren.
>
> Apologies for being grumpy, long day :)
No worries. I get it.
> to be clear I value your and
> Vlastimil's feedback very much, and thanks to you both for having taken the
> time to review the rework.
The cleanup you did may not be the most exciting work you do but it
really aids understanding the code and its intent. Thanks for doing
that!
>
> Hopefully that's reflected in just how much I've updated the series in
> response to both your absolutely valid pointing out of mistakes as well as
> suggestions for improvements, I think the series is way better with your
> input! (As always with code review - it is just a net positive).
That's my goal.
>
> Please do review the new revision with scrutiny and comment on anything you
> find that you feel I should update, including this issue, perhaps I simply
> misunderstood you, but hopefully you can also see my point of view as to
> why I felt it was useful to factor that out.
I started reviewing new patches but need to check the important ones
with fresh eyes. Will finish them tomorrow morning.
>
> In general I'm hoping to move away from cleanups and towards meatier series
> but as co-maintainer of the VMA locks I felt it really important to make
> the VMA locks logic a lot clearer - to not just complain but do something
> :)
>
> In general the issue has been around abstraction at the 'intermediate'
> level as Vlasta describes it, the public API is fine, so just rearranging
> things such that developers coming to the code can build a good mental
> model of what's going on.
>
> So hopefully this series helps get us a least a decent way along that road!
It definitely does. Thanks again for doing this!
Cheers,
Suren.
>
> Cheers, Lorenzo
Powered by blists - more mailing lists