Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1440435imu; Fri, 7 Dec 2018 23:17:40 -0800 (PST) X-Google-Smtp-Source: AFSGD/WFhVRYX1XocR3qb8kIqw1zeIMDdQzmgEASK0FGyO7EH7239vUgoTudAO1MX4foTLoV7Tct X-Received: by 2002:a62:4e83:: with SMTP id c125mr5111965pfb.101.1544253460201; Fri, 07 Dec 2018 23:17:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544253460; cv=none; d=google.com; s=arc-20160816; b=VckGTD8BZ1VS+X4W5LxIT9pmXhLTGMYP2v3bEt6oh1wfrOJ24i0OuECbUCy5UAMzte OrEMcjyRJTOHZpvL6lg+Gkk0Q5+NnBLC0y2vK4HyF/NttcBG4vgxPCZagoFh0XPkSGQs urzjfqAUlNh8V15hBB9TTGHdCKP1vUJxnMHBStBI2J3P1qg1JI+GdcPNVy+8pPT1Bb7r a0tYSbVrd+1x33YqIw07aclIO8Zhx6Zqo7pBq0o1cIw7dLWWwGJGRovT++lfiWuMX9NE 6tVNMXzlgXF1SW8RvnHqb653dJZ1VmDm18JnePXGiMNwpAyauARElz4gfc47M0zAscu4 /4tw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=C3H6N6h2pzHR9OK+frkAK7GAwYbsLQzo4rb364b097U=; b=rTcg9qLqzOzKmhYSmzKBbP+N2FIWhOoCfOk4yGZVpq6srw49P0yn6bm+dyC+ks02rG 56dwFVZhS1HyVXmXKJ/bfH1V1+jnnQ6qAZ1RIcMxQvOymhqk3bsGBJ11trbNTKOv9goS RhrBmWiGBPeJWMJQ3WY9l/1HztZX4I0dKNpACxaoHuIna58GxJWqOSX2lBgH4kxWUt1s LYlc7HlKhQqlGNq1vezKSDtFxYtXLrIzLBc6vd3a2HOTMBa1WZ1ziA1HUs65WVOv2oXn wHbT5UDEGt8Vza3V0jlFbCiJf95sP5ggNyrgl/do+/49dCiNQ7KkDnDBdwrCtsP59kei XWVA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=rfIdSzmJ; 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 g26si5016666pfe.127.2018.12.07.23.17.23; Fri, 07 Dec 2018 23:17:40 -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; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=rfIdSzmJ; 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 S1726222AbeLHHQp (ORCPT + 99 others); Sat, 8 Dec 2018 02:16:45 -0500 Received: from mail-ot1-f66.google.com ([209.85.210.66]:36368 "EHLO mail-ot1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726121AbeLHHQp (ORCPT ); Sat, 8 Dec 2018 02:16:45 -0500 Received: by mail-ot1-f66.google.com with SMTP id k98so5979544otk.3 for ; Fri, 07 Dec 2018 23:16:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=C3H6N6h2pzHR9OK+frkAK7GAwYbsLQzo4rb364b097U=; b=rfIdSzmJgJl+9k7qSCRMoqm5IzqvPdFFbgt3urW1engf5UV6h51aYVxAFMmy8RXQRk Vnb3VjqQ881bUOAD/eKJ+/UtoI8XGTeaSkni9gXQgx4iqsTOQKRwYTitrE4mnipZX5mT 19UYMAjgYnN8vpcaiKZaw1mzCA1CAzE5Z/dFXk1Rg57qhw7/7hy7XcPyIuhfo+PJTSVf nNPxKJKQBqqGoSz+q62NEVqsVHDd+sUOV9NiWBAFHjasIXHyy1zlDhPzziojV2LxG/l+ i+WnLRCR9dGUM823CIhO7BrQWjHrXCphoDxwFmWJpRdunt8PVWqgSBhsbr+OUt/HpyM1 4wxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=C3H6N6h2pzHR9OK+frkAK7GAwYbsLQzo4rb364b097U=; b=tVBl7bZOilPMWkl2dEB5yL9i9Ws9UphZAHCHzg9QmqCFbqPy11P0W8haMgwVS5c8If 4ZESEI8diJtEV1g/5ks3/So7+HuZyYVNXOsk4/BP+19cqilh9V+hcNxfYLl+ZW0mGz6f l7pFpyETwnhpJDEgI452cJSORv/Rai/Ae+5/SDwagT2NyK1grYz/uHRySGwhkE3vMDDE /n7V3N4py4P8sKIS+mDGiSGoXx3BmIcI3KRvlodMdxdiyejHJuPB5tVNRO5bEEXme4WW /wpndsiX8jOHbCe8KBWjJl9AHxnUBDhMYp/rhSlYBr/nSMBF8Aif+fIWSN0snsp7CMch GtyA== X-Gm-Message-State: AA+aEWaovDfSsIwOSd831I7w31z52NWB9/zBO3ZSsPbLFCsYWL7Xmfa9 ex3SmoigsfPMYGl5m6vzkEoMer7m716V5DEeC/K8GQ== X-Received: by 2002:a9d:6ac2:: with SMTP id m2mr3331738otq.353.1544253403739; Fri, 07 Dec 2018 23:16:43 -0800 (PST) MIME-Version: 1.0 References: <20181204001720.26138-1-jhubbard@nvidia.com> <20181204001720.26138-2-jhubbard@nvidia.com> <3c91d335-921c-4704-d159-2975ff3a5f20@nvidia.com> <20181205011519.GV10377@bombadil.infradead.org> <20181205014441.GA3045@redhat.com> <59ca5c4b-fd5b-1fc6-f891-c7986d91908e@nvidia.com> <7b4733be-13d3-c790-ff1b-ac51b505e9a6@nvidia.com> <20181207191620.GD3293@redhat.com> <3c4d46c0-aced-f96f-1bf3-725d02f11b60@nvidia.com> In-Reply-To: <3c4d46c0-aced-f96f-1bf3-725d02f11b60@nvidia.com> From: Dan Williams Date: Fri, 7 Dec 2018 23:16:32 -0800 Message-ID: Subject: Re: [PATCH 1/2] mm: introduce put_user_page*(), placeholder versions To: John Hubbard Cc: =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Matthew Wilcox , John Hubbard , Andrew Morton , Linux MM , Jan Kara , tom@talpey.com, Al Viro , benve@cisco.com, Christoph Hellwig , Christopher Lameter , "Dalessandro, Dennis" , Doug Ledford , Jason Gunthorpe , Michal Hocko , Mike Marciniszyn , rcampbell@nvidia.com, Linux Kernel Mailing List , linux-fsdevel Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 7, 2018 at 4:53 PM John Hubbard wrote: > > On 12/7/18 11:16 AM, Jerome Glisse wrote: > > On Thu, Dec 06, 2018 at 06:45:49PM -0800, John Hubbard wrote: [..] > I see. OK, HMM has done an efficient job of mopping up unused fields, and now we are > completely out of space. At this point, after thinking about it carefully, it seems clear > that it's time for a single, new field: > > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h > index 5ed8f6292a53..1c789e324da8 100644 > --- a/include/linux/mm_types.h > +++ b/include/linux/mm_types.h > @@ -182,6 +182,9 @@ struct page { > /* Usage count. *DO NOT USE DIRECTLY*. See page_ref.h */ > atomic_t _refcount; > > + /* DMA usage count. See get_user_pages*(), put_user_page*(). */ > + atomic_t _dma_pinned_count; > + > #ifdef CONFIG_MEMCG > struct mem_cgroup *mem_cgroup; > #endif > > > ...because after all, the reason this is so difficult is that this fix has to work > in pretty much every configuration. get_user_pages() use is widespread, it's a very > general facility, and...it needs fixing. And we're out of space. HMM seems entirely too greedy in this regard. Especially with zero upstream users. When can we start to delete the pieces of HMM that have no upstream consumers? I would think that would be 4.21 / 5.0 as there needs to be some forcing function. We can always re-add pieces of HMM with it's users when / if they arrive.