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 14:04:35 -0400 [thread overview]
Message-ID: <YMJUM4sx1VclR7oz@t490s> (raw)
In-Reply-To: <2773835.D95cIkl9rl@nvdebian>
On Thu, Jun 10, 2021 at 10:18:25AM +1000, Alistair Popple wrote:
> > > The main problem is split_huge_pmd_address() unconditionally calls a mmu
> > > notifier so I would need to plumb in passing an owner everywhere which could
> > > get messy.
> >
> > Could I ask why? split_huge_pmd_address() will notify with CLEAR, so I'm a bit
> > confused why we need to pass over the owner.
>
> Sure, it is the same reason we need to pass it for the exclusive notifier.
> Any invalidation during the make exclusive operation will break the mmu read
> side critical section forcing a retry of the operation. The owner field is what
> is used to filter out invalidations (such as the exclusive invalidation) that
> don't need to be retried.
Do you mean the mmu_interval_read_begin|retry() calls?
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.
If that's the case, I think it fails because split_huge_pmd_address() will
trigger that CLEAR notify unconditionally (even if it's not a thp; not sure
whether it should be optimized to not notify at all... definitely another
story), while FOLL_SPLIT_PMD will skip the notify as it calls split_huge_pmd()
instead, who checks the pmd before calling __split_huge_pmd().
Does it also mean that if there's a real THP it won't really work? As then
FOLL_SPLIT_PMD will start to trigger that CLEAR notify too, I think..
--
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, 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 14:04:35 -0400 [thread overview]
Message-ID: <YMJUM4sx1VclR7oz@t490s> (raw)
In-Reply-To: <2773835.D95cIkl9rl@nvdebian>
On Thu, Jun 10, 2021 at 10:18:25AM +1000, Alistair Popple wrote:
> > > The main problem is split_huge_pmd_address() unconditionally calls a mmu
> > > notifier so I would need to plumb in passing an owner everywhere which could
> > > get messy.
> >
> > Could I ask why? split_huge_pmd_address() will notify with CLEAR, so I'm a bit
> > confused why we need to pass over the owner.
>
> Sure, it is the same reason we need to pass it for the exclusive notifier.
> Any invalidation during the make exclusive operation will break the mmu read
> side critical section forcing a retry of the operation. The owner field is what
> is used to filter out invalidations (such as the exclusive invalidation) that
> don't need to be retried.
Do you mean the mmu_interval_read_begin|retry() calls?
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.
If that's the case, I think it fails because split_huge_pmd_address() will
trigger that CLEAR notify unconditionally (even if it's not a thp; not sure
whether it should be optimized to not notify at all... definitely another
story), while FOLL_SPLIT_PMD will skip the notify as it calls split_huge_pmd()
instead, who checks the pmd before calling __split_huge_pmd().
Does it also mean that if there's a real THP it won't really work? As then
FOLL_SPLIT_PMD will start to trigger that CLEAR notify too, I think..
--
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 14:04:35 -0400 [thread overview]
Message-ID: <YMJUM4sx1VclR7oz@t490s> (raw)
In-Reply-To: <2773835.D95cIkl9rl@nvdebian>
On Thu, Jun 10, 2021 at 10:18:25AM +1000, Alistair Popple wrote:
> > > The main problem is split_huge_pmd_address() unconditionally calls a mmu
> > > notifier so I would need to plumb in passing an owner everywhere which could
> > > get messy.
> >
> > Could I ask why? split_huge_pmd_address() will notify with CLEAR, so I'm a bit
> > confused why we need to pass over the owner.
>
> Sure, it is the same reason we need to pass it for the exclusive notifier.
> Any invalidation during the make exclusive operation will break the mmu read
> side critical section forcing a retry of the operation. The owner field is what
> is used to filter out invalidations (such as the exclusive invalidation) that
> don't need to be retried.
Do you mean the mmu_interval_read_begin|retry() calls?
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.
If that's the case, I think it fails because split_huge_pmd_address() will
trigger that CLEAR notify unconditionally (even if it's not a thp; not sure
whether it should be optimized to not notify at all... definitely another
story), while FOLL_SPLIT_PMD will skip the notify as it calls split_huge_pmd()
instead, who checks the pmd before calling __split_huge_pmd().
Does it also mean that if there's a real THP it won't really work? As then
FOLL_SPLIT_PMD will start to trigger that CLEAR notify too, I think..
--
Peter Xu
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
next prev parent reply other threads:[~2021-06-10 18: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 ` [Nouveau] " Alistair Popple
2021-06-07 7:58 ` Alistair Popple
2021-06-07 7:58 ` [PATCH v10 01/10] mm: Remove special swap entry functions Alistair Popple
2021-06-07 7:58 ` [Nouveau] " Alistair Popple
2021-06-07 7:58 ` 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 ` [Nouveau] " Alistair Popple
2021-06-07 7:58 ` 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 ` [Nouveau] " Alistair Popple
2021-06-07 7:58 ` 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 ` [Nouveau] " Alistair Popple
2021-06-07 7:58 ` Alistair Popple
2021-06-07 7:58 ` [PATCH v10 05/10] mm: Rename migrate_pgmap_owner Alistair Popple
2021-06-07 7:58 ` [Nouveau] " Alistair Popple
2021-06-07 7:58 ` Alistair Popple
2021-06-08 15:16 ` Peter Xu
2021-06-08 15:16 ` [Nouveau] " Peter Xu
2021-06-08 15:16 ` 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 ` [Nouveau] " Alistair Popple
2021-06-07 7:58 ` Alistair Popple
2021-06-08 15:19 ` Peter Xu
2021-06-08 15:19 ` [Nouveau] " Peter Xu
2021-06-08 15:19 ` Peter Xu
2021-06-07 7:58 ` [PATCH v10 07/10] mm: Device exclusive memory access Alistair Popple
2021-06-07 7:58 ` [Nouveau] " Alistair Popple
2021-06-07 7:58 ` Alistair Popple
2021-06-08 18:33 ` Peter Xu
2021-06-08 18:33 ` [Nouveau] " Peter Xu
2021-06-08 18:33 ` Peter Xu
2021-06-09 9:38 ` [Nouveau] " Alistair Popple
2021-06-09 9:38 ` Alistair Popple
2021-06-09 9:38 ` Alistair Popple
2021-06-09 16:05 ` Peter Xu
2021-06-09 16:05 ` [Nouveau] " Peter Xu
2021-06-09 16:05 ` Peter Xu
2021-06-10 0:18 ` [Nouveau] " Alistair Popple
2021-06-10 0:18 ` Alistair Popple
2021-06-10 0:18 ` Alistair Popple
2021-06-10 18:04 ` Peter Xu [this message]
2021-06-10 18:04 ` [Nouveau] " Peter Xu
2021-06-10 18:04 ` Peter Xu
2021-06-10 14:21 ` [Nouveau] " Alistair Popple
2021-06-10 14:21 ` Alistair Popple
2021-06-10 14:21 ` Alistair Popple
2021-06-10 23:04 ` Peter Xu
2021-06-10 23:04 ` [Nouveau] " Peter Xu
2021-06-10 23:04 ` Peter Xu
2021-06-10 23:17 ` [Nouveau] " Alistair Popple
2021-06-10 23:17 ` Alistair Popple
2021-06-10 23:17 ` Alistair Popple
2021-06-11 1:00 ` Peter Xu
2021-06-11 1:00 ` [Nouveau] " Peter Xu
2021-06-11 1:00 ` Peter Xu
2021-06-11 3:43 ` [Nouveau] " Alistair Popple
2021-06-11 3:43 ` Alistair Popple
2021-06-11 3:43 ` Alistair Popple
2021-06-11 15:01 ` Peter Xu
2021-06-11 15:01 ` [Nouveau] " Peter Xu
2021-06-11 15:01 ` Peter Xu
2021-06-15 3:08 ` [Nouveau] " Alistair Popple
2021-06-15 3:08 ` Alistair Popple
2021-06-15 3:08 ` Alistair Popple
2021-06-15 16:25 ` Peter Xu
2021-06-15 16:25 ` [Nouveau] " Peter Xu
2021-06-15 16:25 ` Peter Xu
2021-06-16 2:47 ` [Nouveau] " Alistair Popple
2021-06-16 2:47 ` Alistair Popple
2021-06-16 2:47 ` 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
-- strict thread matches above, loose matches on Subject: below --
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=YMJUM4sx1VclR7oz@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.