From: Peter Xu <peterx@redhat.com>
To: Alistair Popple <apopple@nvidia.com>
Cc: linux-mm@kvack.org, akpm@linux-foundation.org,
rcampbell@nvidia.com, linux-doc@vger.kernel.org,
nouveau@lists.freedesktop.org, hughd@google.com,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
hch@infradead.org, bskeggs@redhat.com, jgg@nvidia.com,
shakeelb@google.com, jhubbard@nvidia.com, willy@infradead.org,
Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH v10 07/10] mm: Device exclusive memory access
Date: Thu, 10 Jun 2021 19:04:19 -0400 [thread overview]
Message-ID: <YMKacyNstEM9brUD@t490s> (raw)
In-Reply-To: <6429491.QiJgnDeYu7@nvdebian>
On Fri, Jun 11, 2021 at 12:21:26AM +1000, Alistair Popple wrote:
> > Hmm, the thing is.. to me FOLL_SPLIT_PMD should have similar effect to explicit
> > call split_huge_pmd_address(), afaict. Since both of them use __split_huge_pmd()
> > internally which will generate that unwanted CLEAR notify.
>
> Agree that gup calls __split_huge_pmd() via split_huge_pmd_address()
> which will always CLEAR. However gup only calls split_huge_pmd_address() if it
> finds a thp pmd. In follow_pmd_mask() we have:
>
> if (likely(!pmd_trans_huge(pmdval)))
> return follow_page_pte(vma, address, pmd, flags, &ctx->pgmap);
>
> So I don't think we have a problem here.
Sorry I didn't follow here.. We do FOLL_SPLIT_PMD after this check, right? I
mean, if it's a thp for the current mm, afaict pmd_trans_huge() should return
true above, so we'll skip follow_page_pte(); then we'll check FOLL_SPLIT_PMD
and do the split, then the CLEAR notify. Hmm.. Did I miss something?
--
Peter Xu
WARNING: multiple messages have this Message-ID (diff)
From: Peter Xu <peterx@redhat.com>
To: Alistair Popple <apopple@nvidia.com>
Cc: rcampbell@nvidia.com, willy@infradead.org,
linux-doc@vger.kernel.org, nouveau@lists.freedesktop.org,
hughd@google.com, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org, hch@infradead.org,
linux-mm@kvack.org, shakeelb@google.com, bskeggs@redhat.com,
jgg@nvidia.com, akpm@linux-foundation.org,
Christoph Hellwig <hch@lst.de>
Subject: Re: [Nouveau] [PATCH v10 07/10] mm: Device exclusive memory access
Date: Thu, 10 Jun 2021 19:04:19 -0400 [thread overview]
Message-ID: <YMKacyNstEM9brUD@t490s> (raw)
In-Reply-To: <6429491.QiJgnDeYu7@nvdebian>
On Fri, Jun 11, 2021 at 12:21:26AM +1000, Alistair Popple wrote:
> > Hmm, the thing is.. to me FOLL_SPLIT_PMD should have similar effect to explicit
> > call split_huge_pmd_address(), afaict. Since both of them use __split_huge_pmd()
> > internally which will generate that unwanted CLEAR notify.
>
> Agree that gup calls __split_huge_pmd() via split_huge_pmd_address()
> which will always CLEAR. However gup only calls split_huge_pmd_address() if it
> finds a thp pmd. In follow_pmd_mask() we have:
>
> if (likely(!pmd_trans_huge(pmdval)))
> return follow_page_pte(vma, address, pmd, flags, &ctx->pgmap);
>
> So I don't think we have a problem here.
Sorry I didn't follow here.. We do FOLL_SPLIT_PMD after this check, right? I
mean, if it's a thp for the current mm, afaict pmd_trans_huge() should return
true above, so we'll skip follow_page_pte(); then we'll check FOLL_SPLIT_PMD
and do the split, then the CLEAR notify. Hmm.. Did I miss something?
--
Peter Xu
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
WARNING: multiple messages have this Message-ID (diff)
From: Peter Xu <peterx@redhat.com>
To: Alistair Popple <apopple@nvidia.com>
Cc: rcampbell@nvidia.com, willy@infradead.org,
linux-doc@vger.kernel.org, nouveau@lists.freedesktop.org,
hughd@google.com, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org, hch@infradead.org,
linux-mm@kvack.org, shakeelb@google.com, bskeggs@redhat.com,
jgg@nvidia.com, jhubbard@nvidia.com, akpm@linux-foundation.org,
Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH v10 07/10] mm: Device exclusive memory access
Date: Thu, 10 Jun 2021 19:04:19 -0400 [thread overview]
Message-ID: <YMKacyNstEM9brUD@t490s> (raw)
In-Reply-To: <6429491.QiJgnDeYu7@nvdebian>
On Fri, Jun 11, 2021 at 12:21:26AM +1000, Alistair Popple wrote:
> > Hmm, the thing is.. to me FOLL_SPLIT_PMD should have similar effect to explicit
> > call split_huge_pmd_address(), afaict. Since both of them use __split_huge_pmd()
> > internally which will generate that unwanted CLEAR notify.
>
> Agree that gup calls __split_huge_pmd() via split_huge_pmd_address()
> which will always CLEAR. However gup only calls split_huge_pmd_address() if it
> finds a thp pmd. In follow_pmd_mask() we have:
>
> if (likely(!pmd_trans_huge(pmdval)))
> return follow_page_pte(vma, address, pmd, flags, &ctx->pgmap);
>
> So I don't think we have a problem here.
Sorry I didn't follow here.. We do FOLL_SPLIT_PMD after this check, right? I
mean, if it's a thp for the current mm, afaict pmd_trans_huge() should return
true above, so we'll skip follow_page_pte(); then we'll check FOLL_SPLIT_PMD
and do the split, then the CLEAR notify. Hmm.. Did I miss something?
--
Peter Xu
next prev parent reply other threads:[~2021-06-10 23:04 UTC|newest]
Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-07 7:58 [PATCH v10 00/10] Add support for SVM atomics in Nouveau Alistair Popple
2021-06-07 7:58 ` Alistair Popple
2021-06-07 7:58 ` [Nouveau] " Alistair Popple
2021-06-07 7:58 ` [PATCH v10 01/10] mm: Remove special swap entry functions Alistair Popple
2021-06-07 7:58 ` Alistair Popple
2021-06-07 7:58 ` [Nouveau] " Alistair Popple
2021-06-07 7:58 ` [PATCH v10 02/10] mm/swapops: Rework swap entry manipulation code Alistair Popple
2021-06-07 7:58 ` Alistair Popple
2021-06-07 7:58 ` [Nouveau] " Alistair Popple
2021-06-07 7:58 ` [PATCH v10 03/10] mm/rmap: Split try_to_munlock from try_to_unmap Alistair Popple
2021-06-07 7:58 ` Alistair Popple
2021-06-07 7:58 ` [Nouveau] " Alistair Popple
2021-06-07 7:58 ` [PATCH v10 04/10] mm/rmap: Split migration into its own function Alistair Popple
2021-06-07 7:58 ` Alistair Popple
2021-06-07 7:58 ` [Nouveau] " Alistair Popple
2021-06-07 7:58 ` [PATCH v10 05/10] mm: Rename migrate_pgmap_owner Alistair Popple
2021-06-07 7:58 ` Alistair Popple
2021-06-07 7:58 ` [Nouveau] " Alistair Popple
2021-06-08 15:16 ` Peter Xu
2021-06-08 15:16 ` Peter Xu
2021-06-08 15:16 ` [Nouveau] " Peter Xu
2021-06-07 7:58 ` [PATCH v10 06/10] mm/memory.c: Allow different return codes for copy_nonpresent_pte() Alistair Popple
2021-06-07 7:58 ` Alistair Popple
2021-06-07 7:58 ` [Nouveau] " Alistair Popple
2021-06-08 15:19 ` Peter Xu
2021-06-08 15:19 ` Peter Xu
2021-06-08 15:19 ` [Nouveau] " Peter Xu
2021-06-07 7:58 ` [PATCH v10 07/10] mm: Device exclusive memory access Alistair Popple
2021-06-07 7:58 ` Alistair Popple
2021-06-07 7:58 ` [Nouveau] " Alistair Popple
2021-06-08 18:33 ` Peter Xu
2021-06-08 18:33 ` Peter Xu
2021-06-08 18:33 ` [Nouveau] " Peter Xu
2021-06-09 9:38 ` Alistair Popple
2021-06-09 9:38 ` Alistair Popple
2021-06-09 9:38 ` [Nouveau] " Alistair Popple
2021-06-09 16:05 ` Peter Xu
2021-06-09 16:05 ` Peter Xu
2021-06-09 16:05 ` [Nouveau] " Peter Xu
2021-06-10 0:18 ` Alistair Popple
2021-06-10 0:18 ` Alistair Popple
2021-06-10 0:18 ` [Nouveau] " Alistair Popple
2021-06-10 18:04 ` Peter Xu
2021-06-10 18:04 ` Peter Xu
2021-06-10 18:04 ` [Nouveau] " Peter Xu
2021-06-10 14:21 ` Alistair Popple
2021-06-10 14:21 ` Alistair Popple
2021-06-10 14:21 ` [Nouveau] " Alistair Popple
2021-06-10 23:04 ` Peter Xu [this message]
2021-06-10 23:04 ` Peter Xu
2021-06-10 23:04 ` [Nouveau] " Peter Xu
2021-06-10 23:17 ` Alistair Popple
2021-06-10 23:17 ` Alistair Popple
2021-06-10 23:17 ` [Nouveau] " Alistair Popple
2021-06-11 1:00 ` Peter Xu
2021-06-11 1:00 ` Peter Xu
2021-06-11 1:00 ` [Nouveau] " Peter Xu
2021-06-11 3:43 ` Alistair Popple
2021-06-11 3:43 ` Alistair Popple
2021-06-11 3:43 ` [Nouveau] " Alistair Popple
2021-06-11 15:01 ` Peter Xu
2021-06-11 15:01 ` Peter Xu
2021-06-11 15:01 ` [Nouveau] " Peter Xu
2021-06-15 3:08 ` Alistair Popple
2021-06-15 3:08 ` Alistair Popple
2021-06-15 3:08 ` [Nouveau] " Alistair Popple
2021-06-15 16:25 ` Peter Xu
2021-06-15 16:25 ` Peter Xu
2021-06-15 16:25 ` [Nouveau] " Peter Xu
2021-06-16 2:47 ` Alistair Popple
2021-06-16 2:47 ` Alistair Popple
2021-06-16 2:47 ` [Nouveau] " Alistair Popple
2021-06-07 7:58 ` [PATCH v10 08/10] mm: Selftests for exclusive device memory Alistair Popple
2021-06-07 7:58 ` Alistair Popple
2021-06-07 7:58 ` [Nouveau] " Alistair Popple
2021-06-07 7:58 ` [PATCH v10 09/10] nouveau/svm: Refactor nouveau_range_fault Alistair Popple
2021-06-07 7:58 ` Alistair Popple
2021-06-07 7:58 ` [Nouveau] " Alistair Popple
2021-06-07 7:58 ` [PATCH v10 10/10] nouveau/svm: Implement atomic SVM access Alistair Popple
2021-06-07 7:58 ` Alistair Popple
2021-06-07 7:58 ` [Nouveau] " Alistair Popple
2021-06-09 23:02 [PATCH v10 07/10] mm: Device exclusive memory access kernel test robot
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=YMKacyNstEM9brUD@t490s \
--to=peterx@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=bskeggs@redhat.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=hch@infradead.org \
--cc=hch@lst.de \
--cc=hughd@google.com \
--cc=jgg@nvidia.com \
--cc=jhubbard@nvidia.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nouveau@lists.freedesktop.org \
--cc=rcampbell@nvidia.com \
--cc=shakeelb@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.