From: Shakeel Butt <[email protected]>
To: Lorenzo Stoakes <[email protected]>
Cc: SeongJae Park <[email protected]>,
David Hildenbrand <[email protected]>,
[email protected], Vlastimil Babka <[email protected]>,
Andrew Morton <[email protected]>,
Jens Axboe <[email protected]>,
Pavel Begunkov <[email protected]>,
[email protected], [email protected],
[email protected], [email protected]
Subject: Re: [RFC PATCH] mm/madvise: remove redundant mmap_lock operations from process_madvise()
Date: Tue, 14 Jan 2025 13:55:03 -0800 [thread overview]
Message-ID: <lnmrfp6f6gucw4oxxdk77bgbrogvepvpxl2kp3teje7iuwn7y5@6jjtkcmwnlmf> (raw)
In-Reply-To: <[email protected]>
On Tue, Jan 14, 2025 at 06:47:15PM +0000, Lorenzo Stoakes wrote:
> On Tue, Jan 14, 2025 at 10:13:40AM -0800, Shakeel Butt wrote:
> > Ccing relevant folks.
>
> Thanks Shakeel!
>
> 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.
>
> 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 :)
>
SJ is planning to do couple more optimizations like single tree
traversal (where possible) and batching TLB flushing for advices which
does TLB flushing. It is better to coordinate the work than orthogonally
repeating the work.
Thanks Lorenzo for your time.
Shakeel
next prev parent reply other threads:[~2025-01-14 21:55 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-11 0:46 [RFC PATCH] mm/madvise: remove redundant mmap_lock operations from process_madvise() SeongJae Park
2025-01-14 18:13 ` Shakeel Butt
2025-01-14 18:47 ` Lorenzo Stoakes
2025-01-14 19:54 ` SeongJae Park
2025-01-14 21:55 ` Shakeel Butt [this message]
2025-01-15 3:44 ` Liam R. Howlett
2025-01-15 4:17 ` SeongJae Park
2025-01-15 4:35 ` Honggyu Kim
2025-01-15 6:19 ` SeongJae Park
2025-01-15 7:15 ` Honggyu Kim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=lnmrfp6f6gucw4oxxdk77bgbrogvepvpxl2kp3teje7iuwn7y5@6jjtkcmwnlmf \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox