From: Jason Gunthorpe <jgg@nvidia.com>
To: John Hubbard <jhubbard@nvidia.com>
Cc: David Hildenbrand <david@redhat.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Andrew Morton <akpm@linux-foundation.org>,
Mel Gorman <mgorman@suse.de>,
"Matthew Wilcox (Oracle)" <willy@infradead.org>,
Andrea Arcangeli <aarcange@redhat.com>,
Hugh Dickins <hughd@google.com>, Peter Xu <peterx@redhat.com>
Subject: Re: [PATCH v1 2/3] mm/gup: use gup_can_follow_protnone() also in GUP-fast
Date: Tue, 30 Aug 2022 19:39:23 -0300 [thread overview]
Message-ID: <Yw6RmxslqPrK22H4@nvidia.com> (raw)
In-Reply-To: <391bcb8c-faaa-905b-4dae-b674828a6a37@nvidia.com>
On Tue, Aug 30, 2022 at 01:12:53PM -0700, John Hubbard wrote:
> As long as we continue to sort-of-accidentally use atomic_add_unless(),
> which returns a value, instead of atomic_add(), which does not. :)
I should say I didn't have time to carefully check what put_page was
doing, but IIRC it is an atomic_dec_return to decide if it should free
the page.
The conditional is pretty much inherent to the model, because 0 is
special it always has to be checked. Not so accidental
But you might make the case that these could be the relaxed versions
of the atomic...
> Likewise on the put_page() side: we are depending on the somewhat
> accidental (from the perspective of memory barriers) use of
> atomics that return values.
>
> Maybe it would be good to add a little note at each site, to that
> effect?
It would be fantastic if things that are required to be
acquire/releases are documented as acquire/release :)
It is incredibly subtle stuff and all carefully inlined for maximum
performance.
Jason
next prev parent reply other threads:[~2022-08-30 22:39 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-25 16:46 [PATCH v1 0/3] mm: minor cleanups around NUMA hinting David Hildenbrand
2022-08-25 16:46 ` [PATCH v1 1/3] mm/gup: replace FOLL_NUMA by gup_can_follow_protnone() David Hildenbrand
2022-08-25 16:46 ` [PATCH v1 2/3] mm/gup: use gup_can_follow_protnone() also in GUP-fast David Hildenbrand
2022-08-26 14:59 ` David Hildenbrand
2022-08-30 18:23 ` David Hildenbrand
2022-08-30 18:45 ` Jason Gunthorpe
2022-08-30 18:53 ` David Hildenbrand
2022-08-30 19:18 ` John Hubbard
2022-08-30 19:23 ` David Hildenbrand
2022-08-30 23:44 ` Jason Gunthorpe
2022-08-31 7:44 ` David Hildenbrand
2022-08-31 16:21 ` Peter Xu
2022-08-31 16:31 ` David Hildenbrand
2022-08-31 18:23 ` Peter Xu
2022-08-31 19:25 ` David Hildenbrand
2022-09-01 7:55 ` Alistair Popple
2022-08-30 19:57 ` Jason Gunthorpe
2022-08-30 20:12 ` John Hubbard
2022-08-30 22:39 ` Jason Gunthorpe [this message]
2022-08-31 7:15 ` David Hildenbrand
2022-08-25 16:46 ` [PATCH v1 3/3] mm: fixup documentation regarding pte_numa() and PROT_NUMA David Hildenbrand
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=Yw6RmxslqPrK22H4@nvidia.com \
--to=jgg@nvidia.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=hughd@google.com \
--cc=jhubbard@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=peterx@redhat.com \
--cc=willy@infradead.org \
/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