Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp592803imj; Thu, 7 Feb 2019 08:54:56 -0800 (PST) X-Google-Smtp-Source: AHgI3IZsEbchWawfGdzlP4fVoB4iKqpfcTgxDu6L2XX8mZ5O5UniPL/xHKKvecIknhZ2Sgviy/cl X-Received: by 2002:a62:ea17:: with SMTP id t23mr8689913pfh.46.1549558496548; Thu, 07 Feb 2019 08:54:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549558496; cv=none; d=google.com; s=arc-20160816; b=VULuB7dtNF6c9PojjpzmlK+AecrCrheivRAnBYpK+WGEb5MGOLWNLzMz+BZHcNDk2K EbnJkfGXWsJ7CoP1x2IMWku3rTF+WTTsRm/e5WG+MltEDmOO2dBiLlIC8pMjKZ8KAXoy H+4igtwanvBVzes1RH3jfWFgijzQkg2j0jWdabNvNEYuvSRNVuS2dQDlRp2liHSUG6g/ 88RyHAYrrEAzpj5AYaphvrfazTAinEcH3TdUac06bn1/YnZUwLierjTwSlLZsWNcaHnB k2LRxtXRD9MhXHhCRPrDKuWHpz3eNdZx0D9Z92Uin3qJky73vwb2m0AVkNlMjLZs1CuC 2lOQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=3u7JlvCen7uMA/t/vWJeEiw410szcBl0z8J2T7dsiPo=; b=uVCL0WnTiDINrwzwakEnEnSTmK+JB3LfoPQ09+7pgHvKK0hWRSHgHXzoNXP7+6sE0a Msz2skDuZBb+ztc7G6WWwzmX4dzp3WIi7tQ9Z8doFCRKP2fR/G4ZD77Frtz99t/ELcJg 6eEwrpXYgx7BAU+btaq0Mb5vZWAUZNkev7RLoLaXuANy10Hu4/jq5flJLbrJOsabVas/ 6iAMKc/qJw4n0j7HIpMo70+1UHKPBbzbb4pLclK6aMP/A9ta+zj4HgljRorwzoTxJt/D K/eDyAgjbNBx3BjD74tjU7QvmXczI16PCIABvmhLJkm1P+9RrSM5HBg7fBAWD3doEHMN 81og== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d32si9622749pla.136.2019.02.07.08.54.40; Thu, 07 Feb 2019 08:54:56 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726882AbfBGQy0 (ORCPT + 99 others); Thu, 7 Feb 2019 11:54:26 -0500 Received: from mga09.intel.com ([134.134.136.24]:57468 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726171AbfBGQyZ (ORCPT ); Thu, 7 Feb 2019 11:54:25 -0500 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Feb 2019 08:54:25 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.58,344,1544515200"; d="scan'208";a="142417351" Received: from iweiny-desk2.sc.intel.com ([10.3.52.157]) by fmsmga004.fm.intel.com with ESMTP; 07 Feb 2019 08:54:24 -0800 Date: Thu, 7 Feb 2019 08:54:08 -0800 From: Ira Weiny To: Jason Gunthorpe Cc: Dave Chinner , Doug Ledford , Christopher Lameter , Matthew Wilcox , Jan Kara , lsf-pc@lists.linux-foundation.org, linux-rdma@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, John Hubbard , Jerome Glisse , Dan Williams , Michal Hocko Subject: Re: [LSF/MM TOPIC] Discuss least bad options for resolving longterm-GUP usage by RDMA Message-ID: <20190207165407.GA29531@iweiny-DESK2.sc.intel.com> References: <20190206095000.GA12006@quack2.suse.cz> <20190206173114.GB12227@ziepe.ca> <20190206175233.GN21860@bombadil.infradead.org> <47820c4d696aee41225854071ec73373a273fd4a.camel@redhat.com> <01000168c43d594c-7979fcf8-b9c1-4bda-b29a-500efe001d66-000000@email.amazonses.com> <20190206210356.GZ6173@dastard> <20190206220828.GJ12227@ziepe.ca> <0c868bc615a60c44d618fb0183fcbe0c418c7c83.camel@redhat.com> <20190207035258.GD6173@dastard> <20190207052310.GA22726@ziepe.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190207052310.GA22726@ziepe.ca> User-Agent: Mutt/1.11.1 (2018-12-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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