[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190211221247.GI24692@ziepe.ca>
Date: Mon, 11 Feb 2019 15:12:47 -0700
From: Jason Gunthorpe <jgg@...pe.ca>
To: John Hubbard <jhubbard@...dia.com>
Cc: Ira Weiny <ira.weiny@...el.com>,
Dan Williams <dan.j.williams@...el.com>,
Jan Kara <jack@...e.cz>, Dave Chinner <david@...morbit.com>,
Christopher Lameter <cl@...ux.com>,
Doug Ledford <dledford@...hat.com>,
Matthew Wilcox <willy@...radead.org>,
lsf-pc@...ts.linux-foundation.org,
linux-rdma <linux-rdma@...r.kernel.org>,
Linux MM <linux-mm@...ck.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Jerome Glisse <jglisse@...hat.com>,
Michal Hocko <mhocko@...nel.org>
Subject: Re: [LSF/MM TOPIC] Discuss least bad options for resolving
longterm-GUP usage by RDMA
On Mon, Feb 11, 2019 at 01:22:11PM -0800, John Hubbard wrote:
> The only way that breaks is if longterm pins imply an irreversible action, such
> as blocking and waiting in a way that you can't back out of or get interrupted
> out of. And the design doesn't seem to be going in that direction, right?
RDMA, vfio, etc will always have 'long term' pins that are
irreversible on demand. It is part of the HW capability.
I think the flag is badly named, it is really more of a
GUP_LOCK_PHYSICAL_ADDRESSES flag.
ie indicate to the FS that is should not attempt to remap physical
memory addresses backing this VMA. If the FS can't do that it must
fail.
Short term GUP doesn't need that kind of lock.
Jason
Powered by blists - more mailing lists