From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 87E84C4363A for ; Mon, 26 Oct 2020 20:52:16 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BFEDF2080A for ; Mon, 26 Oct 2020 20:52:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=nvidia.com header.i=@nvidia.com header.b="f0ZInIoM" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BFEDF2080A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=nvidia.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id CC0AF6B005C; Mon, 26 Oct 2020 16:52:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C6F966B005D; Mon, 26 Oct 2020 16:52:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B85E46B0062; Mon, 26 Oct 2020 16:52:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 8D8576B005C for ; Mon, 26 Oct 2020 16:52:14 -0400 (EDT) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 28C99180AD81A for ; Mon, 26 Oct 2020 20:52:14 +0000 (UTC) X-FDA: 77415274188.09.guide07_21034ab27276 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin09.hostedemail.com (Postfix) with ESMTP id 11001180AD815 for ; Mon, 26 Oct 2020 20:52:14 +0000 (UTC) X-HE-Tag: guide07_21034ab27276 X-Filterd-Recvd-Size: 5074 Received: from hqnvemgate24.nvidia.com (hqnvemgate24.nvidia.com [216.228.121.143]) by imf29.hostedemail.com (Postfix) with ESMTP for ; Mon, 26 Oct 2020 20:52:13 +0000 (UTC) Received: from hqmail.nvidia.com (Not Verified[216.228.121.13]) by hqnvemgate24.nvidia.com (using TLS: TLSv1.2, AES256-SHA) id ; Mon, 26 Oct 2020 13:52:19 -0700 Received: from [10.2.57.113] (10.124.1.5) by HQMAIL107.nvidia.com (172.20.187.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 26 Oct 2020 20:52:08 +0000 Subject: Re: [RFCv2 08/16] KVM: Use GUP instead of copy_from/to_user() to access guest memory To: Matthew Wilcox CC: "Kirill A. Shutemov" , Dave Hansen , Andy Lutomirski , "Peter Zijlstra" , Paolo Bonzini , "Sean Christopherson" , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , David Rientjes , Andrea Arcangeli , Kees Cook , Will Drewry , "Edgecombe, Rick P" , "Kleen, Andi" , "Liran Alon" , Mike Rapoport , , , , , "Kirill A. Shutemov" References: <20201020061859.18385-1-kirill.shutemov@linux.intel.com> <20201020061859.18385-9-kirill.shutemov@linux.intel.com> <20201022114946.GR20115@casper.infradead.org> <30ce6691-fd70-76a2-8b61-86d207c88713@nvidia.com> <20201026042158.GN20115@casper.infradead.org> <20201026132830.GQ20115@casper.infradead.org> From: John Hubbard Message-ID: Date: Mon, 26 Oct 2020 13:52:07 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <20201026132830.GQ20115@casper.infradead.org> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.124.1.5] X-ClientProxiedBy: HQMAIL111.nvidia.com (172.20.187.18) To HQMAIL107.nvidia.com (172.20.187.13) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1603745539; bh=En7RBhVPDASyx1ikAPEMmxLBTKzCwYVMSmAZAOLt4F0=; h=Subject:To:CC:References:From:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type:Content-Language: Content-Transfer-Encoding:X-Originating-IP:X-ClientProxiedBy; b=f0ZInIoMhho0FwiYGbQmy/cFCjcszWJ4ksz0xVHxCfriMfXl/ArnCzev6eJCdK5Kk SKcPrGBhvbj9FFXYX8Kulgwm5LFJf/IF7ahfg9uFG11y1RvMDvuI37jYONs5JdsFSg CxTXCx0QKuCpH2ZkZxYB1l7X5xDV7JdA2Du5WAkA56/8NFydmbJwGc5RoWQehk9kqm Z5+4oEawXJxSHhRq56HXamNmJcwBNs2E97FfuQjnEN8NwaLF/fEVnvK2FXYZeu8GDF /AKMvqHg1ckc040vGzeuNsTOkhUWrgg0uCbyuLSpMP4N+gNEOlUGPQaNqNBEiWf5lp dv+cEOmOP0/IQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 10/26/20 6:28 AM, Matthew Wilcox wrote: > On Sun, Oct 25, 2020 at 09:44:07PM -0700, John Hubbard wrote: >> On 10/25/20 9:21 PM, Matthew Wilcox wrote: >>> I don't think the page pinning approach is ever valid. For file >> >> Could you qualify that? Surely you don't mean that the entire pin_user_pages >> story is a waste of time--I would have expected you to make more noise >> earlier if you thought that, yes? > > I do think page pinning is the wrong approach for everything. I did say Not *everything*, just "pinning for DMA", right? Because I don't recall any viable solutions for Direct IO that avoided gup/pup! Also, back to Case 5: I *could* create a small patchset to change over the very few Case 5 call sites to use "gup, lock_page(), write to page...etc", instead of pup. And also, update pin_user_pages.rst to recommend that approach in similar situations. After all, it's not really a long-term DMA pin, which is really what pin_user_pages*() is intended for. Would that be something you'd like to see happen? It's certainly easy enough to fix that up. And your retroactive NAK is sufficient motivation to do so. > so at the time, and I continue to say so when the opportunity presents > itself. But shouting about it constantly only annoys people, so I don't > generally bother. I have other things to work on, and they're productive, > so I don't need to spend my time arguing. Sure. As a practical matter, I've assumed that page pinning is not going to go away any time soon, so I want it to work properly while it's here. But if there is a viable way to eventually replace dma-pinning with something better, then let's keep thinking about it. I'm glad to help in that area. thanks, -- John Hubbard NVIDIA