Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1929822imu; Sat, 8 Dec 2018 10:10:49 -0800 (PST) X-Google-Smtp-Source: AFSGD/WelJs1LTKKqwQJ1WX3ZklWQPf5VYFXTNMlGrWsfTAD9StblCfLfXNzWt1hlIKSYZSngKIx X-Received: by 2002:a62:4181:: with SMTP id g1mr6593802pfd.45.1544292649852; Sat, 08 Dec 2018 10:10:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544292649; cv=none; d=google.com; s=arc-20160816; b=TggvUvkFHEGSIdrrUvAUef9RKv3jrs8OYr91FiYR/Lpfc9AFncCuqbi8AKiypeRLHS 3FXnYM8n37rUI9zW5XTX/jAXreFVo00/Fc40TDTS49Xl5RSHSXS4jryLz+gVi0Op5qyp Arni/FqL+kgDuJVSy5mKb3pZUcXLIC9pSBjg4MPmxmfiIwd4CgKFR6UaVBA3wXlEbwM2 3tuGS/pEswmRZrqGXJh/Vq8Vs7DE1jIppAZR3JQnycdSTTxNQWNZtJKEq057RtU0rdmq rtpp5ndsLqFWZaIK9sPEBnxt3VgtpEe2GH1JO9cAgAmMAHPV8plVz9AsmN8n0QN0PNDZ gZ+w== 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=xZCyliucxVS/DkKnL8Hdv/o+piVzGFZjY+QblPifbY0=; b=Q4Wfyv7H2CowUD8EReQThhvhR/7l/qrqtG1xmkpjNghO4T5g8eypyw4vqdRAa+CWqt FH2i+tsle6PT/fQPqoVCZq/19T03/8Ic4oIia3ZT0gDb/eqJp44CptoYazKXowYgKLwy B74nYA4JvJAhTN49y9q5NiRa88CYmc6TpYepsjfPb+W+bof8NW9FpjxqNwsS/5zDHa61 HTxsHQ+NIVgzUWS9PEpFO4N3bQetWx+bt+3rM3BOqa0YDH9WicHmzxyREkjdhjBz3ZY4 BU7GMgN/4cJV3Y4VNkquBeWtI/5s54oXOXMqkaEfCJNY1ohh5Ej2ONgF9mhTUZXHpvM8 UwtA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=UV0FTEJZ; 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 f15si5702580plr.144.2018.12.08.10.10.33; Sat, 08 Dec 2018 10:10:49 -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=UV0FTEJZ; 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 S1726254AbeLHSJi (ORCPT + 99 others); Sat, 8 Dec 2018 13:09:38 -0500 Received: from mail-ot1-f67.google.com ([209.85.210.67]:46787 "EHLO mail-ot1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726174AbeLHSJi (ORCPT ); Sat, 8 Dec 2018 13:09:38 -0500 Received: by mail-ot1-f67.google.com with SMTP id w25so6766558otm.13 for ; Sat, 08 Dec 2018 10:09:37 -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=xZCyliucxVS/DkKnL8Hdv/o+piVzGFZjY+QblPifbY0=; b=UV0FTEJZ6mZi/l0fvO71PCLobw5gcd4BynUrOvx+lp2va7XNq6y0f81hOE3LuVtQF+ gn5lWZbcnDIGSMBkQ+8FSMrZuCqsvhdyxk7MO6hQrIuySQ+UJUhCvSGabAoNssVJlOjx XU6X6HS08LJhc2zopArTj8vB/ImrKKYtRQc6IOaHTG6M9IPDZunneH6qHZSakKEgWwPe 5G3no0AYXUDLYuja9Y1oh1TsMO612wZmHW6qEfiMh9Xv+ixK3fdNU38go40jH4g9wInp 4euyaAppslWgZ7VdVcdl5Av2TTsSTgLjKRHG+CoXTmGVcaalaoVrXwGSnXRp8BgrCVyv OfNA== 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=xZCyliucxVS/DkKnL8Hdv/o+piVzGFZjY+QblPifbY0=; b=VY2LGgQv4SZWMvd8PtYQeqF2PJvSi80gz0LhhqNCcaANNXqLj0Z30/89AH+TMzjgo6 ynhTClkGfhl/q5PbM+7UTnIAnTNOf/o5CiCINSzllWlKasgo2SEbVjD01w00b5JR1Fja UBZJwZ8Hs459kzl3+dN954Ba1hfx4sO1xFRIGWz8ddIK607nsaP5l4JWPgmEP2/ysiEO LPg0myBJV97k7JF5xbPqLrqdiK+zbhbhZxhTKiR/mph0dU4bqmGO6wMRI2MSNZ38Pz1Y O0seHZjlf6GYmruwRYJRY1IVPQby8OFTh5zHbQegt9RsU0+Ftz3tKRa5MMK/GezbKVD+ h/XQ== X-Gm-Message-State: AA+aEWZQGZY5bvduMNWORjCZ34pvA5LtoYU2K9hvMkH3zRlBNgim9Rjq xZB3R/AjPhbCbDbV0oGvz4taGfhmhsvQSQmn8fn1jA== X-Received: by 2002:a9d:6a50:: with SMTP id h16mr4237257otn.95.1544292577193; Sat, 08 Dec 2018 10:09:37 -0800 (PST) MIME-Version: 1.0 References: <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> <20181208163353.GA2952@redhat.com> <20181208164825.GA26154@infradead.org> In-Reply-To: <20181208164825.GA26154@infradead.org> From: Dan Williams Date: Sat, 8 Dec 2018 10:09:26 -0800 Message-ID: Subject: Re: [PATCH 1/2] mm: introduce put_user_page*(), placeholder versions To: Christoph Hellwig Cc: =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , John Hubbard , Matthew Wilcox , John Hubbard , Andrew Morton , Linux MM , Jan Kara , tom@talpey.com, Al Viro , benve@cisco.com, 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 Sat, Dec 8, 2018 at 8:48 AM Christoph Hellwig wrote: > > On Sat, Dec 08, 2018 at 11:33:53AM -0500, Jerome Glisse wrote: > > Patchset to use HMM inside nouveau have already been posted, some > > of the bits have already made upstream and more are line up for > > next merge window. > > Even with that it is a relative fringe feature compared to making > something like get_user_pages() that is literally used every to actually > work properly. > > So I think we need to kick out HMM here and just find another place for > it to store data. > > And just to make clear that I'm not picking just on this - the same is > true to a just a little smaller extent for the pgmap.. Fair enough, I cringed as I took a full pointer for that use case, I'm happy to look at ways of consolidating or dropping that usage. Another fix that may put pressure 'struct page' is resolving the untenable situation of dax being incompatible with reflink, i.e. reflink currently requires page-cache pages. Dave has talked about silently establishing page-cache entries when a dax-page is cow'd for reflink, but I wonder if we could go the other way and introduce the mechanism of a page belonging to multiple mappings simultaneously and managed by the filesystem. Both HMM and ZONE_DEVICE in general are guilty of side-stepping the mm and I'm in favor of undoing that as much as possible,