From: Peter Xu <peterx@redhat.com>
To: Alistair Popple <apopple@nvidia.com>
Cc: Jason Gunthorpe <jgg@nvidia.com>,
linux-mm@kvack.org, nouveau@lists.freedesktop.org,
bskeggs@redhat.com, akpm@linux-foundation.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org, jhubbard@nvidia.com,
rcampbell@nvidia.com, jglisse@redhat.com, hch@infradead.org,
daniel@ffwll.ch, willy@infradead.org, bsingharora@gmail.com,
Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH v8 5/8] mm: Device exclusive memory access
Date: Wed, 19 May 2021 10:04:32 -0400 [thread overview]
Message-ID: <YKUa8HZjfFW2Dhb1@t490s> (raw)
In-Reply-To: <2569629.VzlulnA7BY@nvdebian>
On Wed, May 19, 2021 at 11:11:55PM +1000, Alistair Popple wrote:
> On Wednesday, 19 May 2021 10:15:41 PM AEST Peter Xu wrote:
> > External email: Use caution opening links or attachments
> >
> > On Wed, May 19, 2021 at 09:04:53PM +1000, Alistair Popple wrote:
> > > Failing fork() because we couldn't take a lock doesn't seem like the right
> > > approach though, especially as there is already existing code that
> > > retries. I get this adds complexity though, so would be happy to take a
> > > look at cleaning copy_pte_range() up in future.
> >
> > Yes, I proposed that as this one won't affect any existing applications
> > (unlike the existing ones) but only new userspace driver apps that will use
> > this new atomic feature.
> >
> > IMHO it'll be a pity to add extra complexity and maintainance burden into
> > fork() if only for keeping the "logical correctness of fork()" however the
> > code never triggers. If we start with trylock we'll know whether people
> > will use it, since people will complain with a reason when needed; however
> > I still doubt whether a sane userspace device driver should fork() within
> > busy interaction with the device underneath..
>
> I will refrain from commenting on the sanity or otherwise of doing that :-)
>
> Agree such a scenario seems unlikely in practice (and possibly unreasonable).
> Keeping the "logical correctness of fork()" still seems worthwhile to me, but
> if the added complexity/maintenance burden for an admittedly fairly specific
> feature is going to stop progress here I am happy to take the fail fork
> approach. I could then possibly fix it up as a future clean up to
> copy_pte_range(). Perhaps others have thoughts?
Yes, it's more about making this series easier to be accepted, and it'll be
great to have others' input.
Btw, just to mention that I don't even think fail fork() on failed trylock() is
against "logical correctness of fork()": IMHO it's still 100% correct just like
most syscalls can return with -EAGAIN, that suggests the userspace to try again
the syscall, and I hope that also works for fork(). I'd be more than glad to
be corrected too.
--
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, daniel@ffwll.ch,
linux-doc@vger.kernel.org, nouveau@lists.freedesktop.org,
bsingharora@gmail.com, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org, hch@infradead.org,
linux-mm@kvack.org, bskeggs@redhat.com,
Jason Gunthorpe <jgg@nvidia.com>,
akpm@linux-foundation.org, Christoph Hellwig <hch@lst.de>
Subject: Re: [Nouveau] [PATCH v8 5/8] mm: Device exclusive memory access
Date: Wed, 19 May 2021 10:04:32 -0400 [thread overview]
Message-ID: <YKUa8HZjfFW2Dhb1@t490s> (raw)
In-Reply-To: <2569629.VzlulnA7BY@nvdebian>
On Wed, May 19, 2021 at 11:11:55PM +1000, Alistair Popple wrote:
> On Wednesday, 19 May 2021 10:15:41 PM AEST Peter Xu wrote:
> > External email: Use caution opening links or attachments
> >
> > On Wed, May 19, 2021 at 09:04:53PM +1000, Alistair Popple wrote:
> > > Failing fork() because we couldn't take a lock doesn't seem like the right
> > > approach though, especially as there is already existing code that
> > > retries. I get this adds complexity though, so would be happy to take a
> > > look at cleaning copy_pte_range() up in future.
> >
> > Yes, I proposed that as this one won't affect any existing applications
> > (unlike the existing ones) but only new userspace driver apps that will use
> > this new atomic feature.
> >
> > IMHO it'll be a pity to add extra complexity and maintainance burden into
> > fork() if only for keeping the "logical correctness of fork()" however the
> > code never triggers. If we start with trylock we'll know whether people
> > will use it, since people will complain with a reason when needed; however
> > I still doubt whether a sane userspace device driver should fork() within
> > busy interaction with the device underneath..
>
> I will refrain from commenting on the sanity or otherwise of doing that :-)
>
> Agree such a scenario seems unlikely in practice (and possibly unreasonable).
> Keeping the "logical correctness of fork()" still seems worthwhile to me, but
> if the added complexity/maintenance burden for an admittedly fairly specific
> feature is going to stop progress here I am happy to take the fail fork
> approach. I could then possibly fix it up as a future clean up to
> copy_pte_range(). Perhaps others have thoughts?
Yes, it's more about making this series easier to be accepted, and it'll be
great to have others' input.
Btw, just to mention that I don't even think fail fork() on failed trylock() is
against "logical correctness of fork()": IMHO it's still 100% correct just like
most syscalls can return with -EAGAIN, that suggests the userspace to try again
the syscall, and I hope that also works for fork(). I'd be more than glad to
be corrected too.
--
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,
bsingharora@gmail.com, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org, hch@infradead.org,
linux-mm@kvack.org, jglisse@redhat.com, bskeggs@redhat.com,
Jason Gunthorpe <jgg@nvidia.com>,
jhubbard@nvidia.com, akpm@linux-foundation.org,
Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH v8 5/8] mm: Device exclusive memory access
Date: Wed, 19 May 2021 10:04:32 -0400 [thread overview]
Message-ID: <YKUa8HZjfFW2Dhb1@t490s> (raw)
In-Reply-To: <2569629.VzlulnA7BY@nvdebian>
On Wed, May 19, 2021 at 11:11:55PM +1000, Alistair Popple wrote:
> On Wednesday, 19 May 2021 10:15:41 PM AEST Peter Xu wrote:
> > External email: Use caution opening links or attachments
> >
> > On Wed, May 19, 2021 at 09:04:53PM +1000, Alistair Popple wrote:
> > > Failing fork() because we couldn't take a lock doesn't seem like the right
> > > approach though, especially as there is already existing code that
> > > retries. I get this adds complexity though, so would be happy to take a
> > > look at cleaning copy_pte_range() up in future.
> >
> > Yes, I proposed that as this one won't affect any existing applications
> > (unlike the existing ones) but only new userspace driver apps that will use
> > this new atomic feature.
> >
> > IMHO it'll be a pity to add extra complexity and maintainance burden into
> > fork() if only for keeping the "logical correctness of fork()" however the
> > code never triggers. If we start with trylock we'll know whether people
> > will use it, since people will complain with a reason when needed; however
> > I still doubt whether a sane userspace device driver should fork() within
> > busy interaction with the device underneath..
>
> I will refrain from commenting on the sanity or otherwise of doing that :-)
>
> Agree such a scenario seems unlikely in practice (and possibly unreasonable).
> Keeping the "logical correctness of fork()" still seems worthwhile to me, but
> if the added complexity/maintenance burden for an admittedly fairly specific
> feature is going to stop progress here I am happy to take the fail fork
> approach. I could then possibly fix it up as a future clean up to
> copy_pte_range(). Perhaps others have thoughts?
Yes, it's more about making this series easier to be accepted, and it'll be
great to have others' input.
Btw, just to mention that I don't even think fail fork() on failed trylock() is
against "logical correctness of fork()": IMHO it's still 100% correct just like
most syscalls can return with -EAGAIN, that suggests the userspace to try again
the syscall, and I hope that also works for fork(). I'd be more than glad to
be corrected too.
--
Peter Xu
next prev parent reply other threads:[~2021-05-19 14:04 UTC|newest]
Thread overview: 127+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-07 8:42 [PATCH v8 0/8] Add support for SVM atomics in Nouveau Alistair Popple
2021-04-07 8:42 ` Alistair Popple
2021-04-07 8:42 ` [Nouveau] " Alistair Popple
2021-04-07 8:42 ` [PATCH v8 1/8] mm: Remove special swap entry functions Alistair Popple
2021-04-07 8:42 ` Alistair Popple
2021-04-07 8:42 ` [Nouveau] " Alistair Popple
2021-05-18 2:17 ` Peter Xu
2021-05-18 2:17 ` Peter Xu
2021-05-18 2:17 ` [Nouveau] " Peter Xu
2021-05-18 11:58 ` Alistair Popple
2021-05-18 11:58 ` Alistair Popple
2021-05-18 11:58 ` [Nouveau] " Alistair Popple
2021-05-18 14:17 ` Peter Xu
2021-05-18 14:17 ` Peter Xu
2021-05-18 14:17 ` [Nouveau] " Peter Xu
2021-04-07 8:42 ` [PATCH v8 2/8] mm/swapops: Rework swap entry manipulation code Alistair Popple
2021-04-07 8:42 ` Alistair Popple
2021-04-07 8:42 ` [Nouveau] " Alistair Popple
2021-04-07 8:42 ` [PATCH v8 3/8] mm/rmap: Split try_to_munlock from try_to_unmap Alistair Popple
2021-04-07 8:42 ` Alistair Popple
2021-04-07 8:42 ` [Nouveau] " Alistair Popple
2021-05-18 20:04 ` Liam Howlett
2021-05-18 20:04 ` Liam Howlett
2021-05-18 20:04 ` [Nouveau] " Liam Howlett
2021-05-19 12:38 ` Alistair Popple
2021-05-19 12:38 ` Alistair Popple
2021-05-19 12:38 ` [Nouveau] " Alistair Popple
2021-05-20 20:24 ` Liam Howlett
2021-05-20 20:24 ` Liam Howlett
2021-05-20 20:24 ` [Nouveau] " Liam Howlett
2021-05-21 2:23 ` Alistair Popple
2021-05-21 2:23 ` Alistair Popple
2021-05-21 2:23 ` [Nouveau] " Alistair Popple
2021-04-07 8:42 ` [PATCH v8 4/8] mm/rmap: Split migration into its own function Alistair Popple
2021-04-07 8:42 ` Alistair Popple
2021-04-07 8:42 ` [Nouveau] " Alistair Popple
2021-04-07 8:42 ` [PATCH v8 5/8] mm: Device exclusive memory access Alistair Popple
2021-04-07 8:42 ` Alistair Popple
2021-04-07 8:42 ` [Nouveau] " Alistair Popple
2021-05-18 2:08 ` Peter Xu
2021-05-18 2:08 ` Peter Xu
2021-05-18 2:08 ` [Nouveau] " Peter Xu
2021-05-18 13:19 ` Alistair Popple
2021-05-18 13:19 ` Alistair Popple
2021-05-18 13:19 ` [Nouveau] " Alistair Popple
2021-05-18 17:27 ` Peter Xu
2021-05-18 17:27 ` Peter Xu
2021-05-18 17:27 ` [Nouveau] " Peter Xu
2021-05-18 17:33 ` Jason Gunthorpe
2021-05-18 17:33 ` Jason Gunthorpe
2021-05-18 17:33 ` [Nouveau] " Jason Gunthorpe
2021-05-18 18:01 ` Peter Xu
2021-05-18 18:01 ` Peter Xu
2021-05-18 18:01 ` [Nouveau] " Peter Xu
2021-05-18 19:45 ` Jason Gunthorpe
2021-05-18 19:45 ` Jason Gunthorpe
2021-05-18 19:45 ` [Nouveau] " Jason Gunthorpe
2021-05-18 20:29 ` Peter Xu
2021-05-18 20:29 ` Peter Xu
2021-05-18 20:29 ` [Nouveau] " Peter Xu
2021-05-18 23:03 ` Jason Gunthorpe
2021-05-18 23:03 ` Jason Gunthorpe
2021-05-18 23:03 ` [Nouveau] " Jason Gunthorpe
2021-05-18 23:45 ` Peter Xu
2021-05-18 23:45 ` Peter Xu
2021-05-18 23:45 ` [Nouveau] " Peter Xu
2021-05-19 11:04 ` Alistair Popple
2021-05-19 11:04 ` Alistair Popple
2021-05-19 11:04 ` [Nouveau] " Alistair Popple
2021-05-19 12:15 ` Peter Xu
2021-05-19 12:15 ` Peter Xu
2021-05-19 12:15 ` [Nouveau] " Peter Xu
2021-05-19 13:11 ` Alistair Popple
2021-05-19 13:11 ` Alistair Popple
2021-05-19 13:11 ` [Nouveau] " Alistair Popple
2021-05-19 14:04 ` Peter Xu [this message]
2021-05-19 14:04 ` Peter Xu
2021-05-19 14:04 ` [Nouveau] " Peter Xu
2021-05-19 13:28 ` Jason Gunthorpe
2021-05-19 13:28 ` Jason Gunthorpe
2021-05-19 13:28 ` [Nouveau] " Jason Gunthorpe
2021-05-19 14:09 ` Peter Xu
2021-05-19 14:09 ` Peter Xu
2021-05-19 14:09 ` [Nouveau] " Peter Xu
2021-05-19 18:11 ` Jason Gunthorpe
2021-05-19 18:11 ` Jason Gunthorpe
2021-05-19 18:11 ` [Nouveau] " Jason Gunthorpe
2021-05-19 11:35 ` Alistair Popple
2021-05-19 11:35 ` Alistair Popple
2021-05-19 11:35 ` [Nouveau] " Alistair Popple
2021-05-19 12:21 ` Peter Xu
2021-05-19 12:21 ` Peter Xu
2021-05-19 12:21 ` [Nouveau] " Peter Xu
2021-05-19 12:46 ` Alistair Popple
2021-05-19 12:46 ` Alistair Popple
2021-05-19 12:46 ` [Nouveau] " Alistair Popple
2021-05-21 6:53 ` Alistair Popple
2021-05-21 6:53 ` Alistair Popple
2021-05-21 6:53 ` [Nouveau] " Alistair Popple
2021-05-18 21:16 ` Peter Xu
2021-05-18 21:16 ` Peter Xu
2021-05-18 21:16 ` [Nouveau] " Peter Xu
2021-05-19 10:49 ` Alistair Popple
2021-05-19 10:49 ` Alistair Popple
2021-05-19 10:49 ` [Nouveau] " Alistair Popple
2021-05-19 12:24 ` Peter Xu
2021-05-19 12:24 ` Peter Xu
2021-05-19 12:24 ` [Nouveau] " Peter Xu
2021-05-19 12:46 ` Alistair Popple
2021-05-19 12:46 ` Alistair Popple
2021-05-19 12:46 ` [Nouveau] " Alistair Popple
2021-04-07 8:42 ` [PATCH v8 6/8] mm: Selftests for exclusive device memory Alistair Popple
2021-04-07 8:42 ` Alistair Popple
2021-04-07 8:42 ` [Nouveau] " Alistair Popple
2021-04-07 8:42 ` [PATCH v8 7/8] nouveau/svm: Refactor nouveau_range_fault Alistair Popple
2021-04-07 8:42 ` Alistair Popple
2021-04-07 8:42 ` [Nouveau] " Alistair Popple
2021-04-07 8:42 ` [PATCH v8 8/8] nouveau/svm: Implement atomic SVM access Alistair Popple
2021-04-07 8:42 ` Alistair Popple
2021-04-07 8:42 ` [Nouveau] " Alistair Popple
2021-05-21 4:04 ` Ben Skeggs
2021-05-21 4:04 ` Ben Skeggs
2021-05-21 4:04 ` [Nouveau] " Ben Skeggs
2021-05-21 4:04 ` Ben Skeggs
2021-05-06 7:43 ` [PATCH v8 0/8] Add support for SVM atomics in Nouveau Alistair Popple
2021-05-06 7:43 ` Alistair Popple
2021-05-06 7:43 ` [Nouveau] " Alistair Popple
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=YKUa8HZjfFW2Dhb1@t490s \
--to=peterx@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=bsingharora@gmail.com \
--cc=bskeggs@redhat.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=hch@infradead.org \
--cc=hch@lst.de \
--cc=jgg@nvidia.com \
--cc=jglisse@redhat.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=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.