[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20250311205453.85220-1-sj@kernel.org>
Date: Tue, 11 Mar 2025 13:54:53 -0700
From: SeongJae Park <sj@...nel.org>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: SeongJae Park <sj@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
"Liam R. Howlett" <howlett@...il.com>,
David Hildenbrand <david@...hat.com>,
Shakeel Butt <shakeel.butt@...ux.dev>,
Vlastimil Babka <vbabka@...e.cz>,
kernel-team@...a.com,
linux-kernel@...r.kernel.org,
linux-mm@...ck.org
Subject: Re: [PATCH 3/9] mm/madvise: deduplicate madvise_do_behavior() skip case handlings
On Tue, 11 Mar 2025 12:02:48 +0000 Lorenzo Stoakes <lorenzo.stoakes@...cle.com> wrote:
> On Mon, Mar 10, 2025 at 10:23:12AM -0700, SeongJae Park wrote:
> > The logic for checking if a given madvise() request for a single memory
> > range can skip real work, namely madvise_do_behavior(), is duplicated in
> > do_madvise() and vector_madvise(). Split out the logic to a function
> > and resue it.
>
> NIT: typo :)
>
> >
> > Signed-off-by: SeongJae Park <sj@...nel.org>
>
> madvise_set_anon_name() seems to do something similar, but somewhat
> differently... not sure if you address this in a later commit but worth
> looking at too!
Thank you for sharing the good finding! I don't have a plan to address that
for now.
>
> Anyway this seems sane, so:
>
> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Thank you for your review!
>
> Note nits!
>
> > ---
> > mm/madvise.c | 53 +++++++++++++++++++++++++++++-----------------------
> > 1 file changed, 30 insertions(+), 23 deletions(-)
> >
> > diff --git a/mm/madvise.c b/mm/madvise.c
> > index 611db868ae38..764ec1f2475b 100644
> > --- a/mm/madvise.c
> > +++ b/mm/madvise.c
> > @@ -1640,6 +1640,27 @@ static bool is_valid_madvise(unsigned long start, size_t len_in, int behavior)
> > return true;
> > }
> >
> > +/*
> > + * madvise_should_skip() - Return if an madivse request can skip real works.
>
> NIT: 'real works' sounds strange.
>
> I'd say something like 'if the specified behaviour is invalid or nothing
> would occur, we skip this operation. In the former case we return an
> error.'
Thanks for this nice suggestion. I will updte so in the next version.
Thanks,
SJ
[...]
Powered by blists - more mailing lists