[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190207165407.GA29531@iweiny-DESK2.sc.intel.com>
Date: Thu, 7 Feb 2019 08:54:08 -0800
From: Ira Weiny <ira.weiny@...el.com>
To: Jason Gunthorpe <jgg@...pe.ca>
Cc: Dave Chinner <david@...morbit.com>,
Doug Ledford <dledford@...hat.com>,
Christopher Lameter <cl@...ux.com>,
Matthew Wilcox <willy@...radead.org>, Jan Kara <jack@...e.cz>,
lsf-pc@...ts.linux-foundation.org, linux-rdma@...r.kernel.org,
linux-mm@...ck.org, linux-kernel@...r.kernel.org,
John Hubbard <jhubbard@...dia.com>,
Jerome Glisse <jglisse@...hat.com>,
Dan Williams <dan.j.williams@...el.com>,
Michal Hocko <mhocko@...nel.org>
Subject: Re: [LSF/MM TOPIC] Discuss least bad options for resolving
longterm-GUP usage by RDMA
On Wed, Feb 06, 2019 at 10:23:10PM -0700, Jason Gunthorpe wrote:
> On Thu, Feb 07, 2019 at 02:52:58PM +1100, Dave Chinner wrote:
>
> > Requiring ODP capable hardware and applications that control RDMA
> > access to use file leases and be able to cancel/recall client side
> > delegations (like NFS is already able to do!) seems like a pretty
>
> So, what happens on NFS if the revoke takes too long?
This is the fundamental issue with RDMA revoke. With RDMA and some hardware
you are going to end up killing processes. If the decision is that only
processes on non-ODP hardware get killed and the user basically "should not
have done that" then I'm ok with that. However, then we really need to
prevented them from registering the memory in the first place. Which means we
leave in the "longterm" GUP registration and fail those registrations can't be
supported.
Ira
Powered by blists - more mailing lists