[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ZMkDIxFQQljY8Ah1@ziepe.ca>
Date: Tue, 1 Aug 2023 10:05:39 -0300
From: Jason Gunthorpe <jgg@...pe.ca>
To: David Hildenbrand <david@...hat.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Peter Xu <peterx@...hat.com>, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, linux-fsdevel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
liubo <liubo254@...wei.com>,
Matthew Wilcox <willy@...radead.org>,
Hugh Dickins <hughd@...gle.com>,
John Hubbard <jhubbard@...dia.com>,
Mel Gorman <mgorman@...e.de>
Subject: Re: [PATCH v1 0/4] smaps / mm/gup: fix gup_can_follow_protnone
fallout
On Mon, Jul 31, 2023 at 09:00:06PM +0200, David Hildenbrand wrote:
> Their logic is "if it's directly in the page table, create, hand it over. If
> not, please go the slow path.". In many cases user space just touched these
> pages so they are very likely in the page table.
I think it has become pretty confusing, overall.
In my mind 'pin_user_pages_fast()' should be functionally the same as
'pin_user_pages_unlocked()'.
Places call fast if they have no idea about what is under memory,
otherwise they call unlocked if you are pretty sure something is there
that needs the mmap lock to resolve.
If we need different behaviors a GUP flag makes the most sense.
> Always honoring NUMA faults here does not sound like the improvement we
> wanted to have :) ... we actually *don't* want to honor NUMA faults here.
Yeah, I think that is right. We should not really use the CPU running
PUP as any input to a NUMA algorithm.. If we want NUMA'ness then the
PUP user should specify the affinity that makes sense.
Jason
Powered by blists - more mailing lists