[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20250114195458.53517-1-sj@kernel.org>
Date: Tue, 14 Jan 2025 11:54:58 -0800
From: SeongJae Park <sj@...nel.org>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: SeongJae Park <sj@...nel.org>,
Shakeel Butt <shakeel.butt@...ux.dev>,
David Hildenbrand <david@...hat.com>,
Liam.Howlett@...cle.com,
Vlastimil Babka <vbabka@...e.cz>,
Andrew Morton <akpm@...ux-foundation.org>,
Jens Axboe <axboe@...nel.dk>,
Pavel Begunkov <asml.silence@...il.com>,
damon@...ts.linux.dev,
io-uring@...r.kernel.org,
linux-kernel@...r.kernel.org,
linux-mm@...ck.org
Subject: Re: [RFC PATCH] mm/madvise: remove redundant mmap_lock operations from process_madvise()
On Tue, 14 Jan 2025 18:47:15 +0000 Lorenzo Stoakes <lorenzo.stoakes@...cle.com> wrote:
> On Tue, Jan 14, 2025 at 10:13:40AM -0800, Shakeel Butt wrote:
> > Ccing relevant folks.
>
> Thanks Shakeel!
Thank you Shakeel, too!
>
> A side-note, I really wish there was a better way to get cc'd, since I
> fundamentally changed process_madvise() recently and was the main person
> changing this code lately, but on the other hand -
> scripts/get_maintainers.pl gets really really noisy if you try to use this
> kind of stat - so I in no way blame SJ for missing me.
Yes, I always feeling finding not too many, not too less, but only appropriate
recipients for patches is not easy. Just FYI, I use get_maintainers.pl with
--nogit option[1] and add more recipients based on additional logics[2] that
based on my past experiences and discussions, by default. And then I run
get_maintainers.pl without --nogit option if I get no response more than I
expected.
I will keep Shakeel-aded recipients for next spins of this patch, anyway.
>
> Thankfully Shakeel kindly stepped in to make me aware :)
>
> SJ - I will come back to you later, as it's late here and my brain is fried
> - but I was already thinking of doing something _like_ this, as I noticed
> for the purposes of self-process_madvise() operations (which I unrestricted
> for guard page purposes) - we are hammering locks in a way that we know we
> don't necessarily need to do.
>
> So this is serendipitous for me! :) But I need to dig into your actual
> implementation to give feedback here.
>
> Will come back to this in due course :)
No worry, no rush. Please take your time :)
[1] https://github.com/sjp38/hackermail/blob/master/src/hkml_patch_format.py#L45
[2] https://github.com/sjp38/hackermail/blob/master/src/hkml_patch_format.py#L31
Thanks,
SJ
[...]
Powered by blists - more mailing lists