[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZMk7MqApTDZXzwKX@x1n>
Date: Tue, 1 Aug 2023 13:04:50 -0400
From: Peter Xu <peterx@...hat.com>
To: David Hildenbrand <david@...hat.com>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org,
linux-fsdevel@...r.kernel.org, kvm@...r.kernel.org,
linux-kselftest@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
liubo <liubo254@...wei.com>,
Matthew Wilcox <willy@...radead.org>,
Hugh Dickins <hughd@...gle.com>,
Jason Gunthorpe <jgg@...pe.ca>,
John Hubbard <jhubbard@...dia.com>,
Mel Gorman <mgorman@...e.de>, Shuah Khan <shuah@...nel.org>,
Paolo Bonzini <pbonzini@...hat.com>, stable@...r.kernel.org
Subject: Re: [PATCH v2 1/8] mm/gup: reintroduce FOLL_NUMA as
FOLL_HONOR_NUMA_FAULT
On Tue, Aug 01, 2023 at 06:15:48PM +0200, David Hildenbrand wrote:
> On 01.08.23 17:48, Peter Xu wrote:
> > On Tue, Aug 01, 2023 at 02:48:37PM +0200, David Hildenbrand wrote:
> > > @@ -2240,6 +2244,12 @@ static bool is_valid_gup_args(struct page **pages, int *locked,
> > > gup_flags |= FOLL_UNLOCKABLE;
> > > }
> > > + /*
> > > + * For now, always trigger NUMA hinting faults. Some GUP users like
> > > + * KVM really require it to benefit from autonuma.
> > > + */
> > > + gup_flags |= FOLL_HONOR_NUMA_FAULT;
> >
> > Since at it, do we want to not set it for FOLL_REMOTE, which still sounds
> > like a good thing to have?
>
> I thought about that, but decided against making that patch here more
> complicated to eventually rip it again all out in #4.
I thought that was the whole point of having patch 4 separate, because we
should assume patch 4 may not exist in (at least) some trees, so I ignored
patch 4 when commenting here, and we should not assume it's destined to be
removed here.
>
> I fully agree that FOLL_REMOTE does not make too much sense, but let's
> rather keep it simple for this patch.
It's fine - I suppose this patch fixes whatever we're aware of that's
broken with FOLL_NUMA's removal, so it can even be anything on top when
needed. I assume I'm happy to ack this with/without that change, then:
Acked-by: Peter Xu <peterx@...hat.com>
PS: I still hope that the other oneliner can be squashed here directly; it
literally changes exact the same line above so reading this patch alone can
be affected. You said there you didn't want the commit message to be too
long here, but this is definitely not long at all! I bet you have similar
understanding to me on defining "long commit message". :) I'd never worry
that. Your call.
Thanks,
--
Peter Xu
Powered by blists - more mailing lists