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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 D1682C433E0 for ; Tue, 26 Jan 2021 18:20:28 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4F5B4207A9 for ; Tue, 26 Jan 2021 18:20:28 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4F5B4207A9 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 9A56F8D00FE; Tue, 26 Jan 2021 13:20:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 956DB8D00F8; Tue, 26 Jan 2021 13:20:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7F6478D00FE; Tue, 26 Jan 2021 13:20:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0037.hostedemail.com [216.40.44.37]) by kanga.kvack.org (Postfix) with ESMTP id 673D98D00F8 for ; Tue, 26 Jan 2021 13:20:27 -0500 (EST) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 2DC3E8249980 for ; Tue, 26 Jan 2021 18:20:27 +0000 (UTC) X-FDA: 77748741294.06.view06_3e0326727590 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin06.hostedemail.com (Postfix) with ESMTP id 07E231003C0A1 for ; Tue, 26 Jan 2021 18:20:27 +0000 (UTC) X-HE-Tag: view06_3e0326727590 X-Filterd-Recvd-Size: 5872 Received: from mail-qk1-f177.google.com (mail-qk1-f177.google.com [209.85.222.177]) by imf08.hostedemail.com (Postfix) with ESMTP for ; Tue, 26 Jan 2021 18:20:26 +0000 (UTC) Received: by mail-qk1-f177.google.com with SMTP id l27so6427123qki.9 for ; Tue, 26 Jan 2021 10:20:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=3pcCknD/BxtIB8RBkZo8Cp7IF2+vwd74k7zS24kTbR8=; b=g4dYrV4PaU2nmFT29+g3Rzm5JnSUd20A1ZWJ6EdcZinlf0+ZNWNonkfVQ6Dp3gXNCM iJu2ORFJvR2ymNl1/WjeVn9tUusJv6B/KvgegcBmQ+lLLD9FbefZpf21si64F1aicoOd TuRy802BItwrexCICDhtbGPbzg6DJN4LdRpJN7tiwQrpEsyHaBUXEq3AfaOQslLRuF5e xmnc145bBdMdUKni1AZrxpkAvtY0ZQoozUmrlJqyHo2l4q/WuLLfAxAj+BFYkFP1drk5 cjVu7ZEjWMrDw+WqzYGeymS4FdQsB1s+TzvrnDOUgLArhdfwXDigOGQ/NLrHQa+OwxGj HAUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=3pcCknD/BxtIB8RBkZo8Cp7IF2+vwd74k7zS24kTbR8=; b=EDEdz3s5pO7dGLaXpaQ1gAI9rG8udrd3vkWMMGG9F5DH4DjdOWxrcZkZwWnZTXTYQ9 jjVXwSh2G4RfAEiPcGTjHPPoKJjEyUXNURW/jncQnEgnalbY22VG1Hg6Ntgo5yMtkNhS mPt5nRvWvOOuYvhg7Hw4moQ5yQMyK43ZH5wEQnplNL+6q2teOtqCQJMZm2Y6ATH8OHBT JAJLPep1UThw63LYHwHG+jPENEKxv2n69ZfuWE30NTfnBQtxlHb4S/zVEX+9oPyxQhc2 XFWSMjYADOBAsIk+nUo8VinVjKJCwoVz6s1/H+x8AAYYrRhewEEbxcEcIiPZmOz3h4bS gG3w== X-Gm-Message-State: AOAM530BYQVTSHiIWsbwSGti2qSBiCCPVV6F51gYPUsLVH9dUYb+dpbn JdbRz2ioBbQzSF8osqnWOfTKAw== X-Google-Smtp-Source: ABdhPJyv228KfIjwwkPqso1SD69kZ5ZLPyWizKOSKwm7PPgZ1vF7s3nuEYfyIbVsj4pXarwA8sS6PA== X-Received: by 2002:a37:bc8:: with SMTP id 191mr7214911qkl.384.1611685225677; Tue, 26 Jan 2021 10:20:25 -0800 (PST) Received: from ziepe.ca (hlfxns017vw-142-162-115-133.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.162.115.133]) by smtp.gmail.com with ESMTPSA id x72sm12135585qka.51.2021.01.26.10.20.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 Jan 2021 10:20:25 -0800 (PST) Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1l4Swy-0078zV-Bj; Tue, 26 Jan 2021 14:20:24 -0400 Date: Tue, 26 Jan 2021 14:20:24 -0400 From: Jason Gunthorpe To: "Song Bao Hua (Barry Song)" Cc: "Wangzhou (B)" , Greg Kroah-Hartman , Arnd Bergmann , Zhangfei Gao , "linux-accelerators@lists.ozlabs.org" , "linux-kernel@vger.kernel.org" , "iommu@lists.linux-foundation.org" , "linux-mm@kvack.org" , "Liguozhu (Kenneth)" , "chensihang (A)" Subject: Re: [RFC PATCH v2] uacce: Add uacce_ctrl misc device Message-ID: <20210126182024.GA4605@ziepe.ca> References: <1611563696-235269-1-git-send-email-wangzhou1@hisilicon.com> <20210125154717.GW4605@ziepe.ca> <96b655ade2534a65974a378bb68383ee@hisilicon.com> <20210125231619.GY4605@ziepe.ca> <5f64a68042c64f37b5cba74028bd2189@hisilicon.com> <20210126011304.GZ4605@ziepe.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Tue, Jan 26, 2021 at 01:26:45AM +0000, Song Bao Hua (Barry Song) wrote: > > On Mon, Jan 25, 2021 at 11:35:22PM +0000, Song Bao Hua (Barry Song) wrote: > > > > > > On Mon, Jan 25, 2021 at 10:21:14PM +0000, Song Bao Hua (Barry Song) wrote: > > > > > mlock, while certainly be able to prevent swapping out, it won't > > > > > be able to stop page moving due to: > > > > > * memory compaction in alloc_pages() > > > > > * making huge pages > > > > > * numa balance > > > > > * memory compaction in CMA > > > > > > > > Enabling those things is a major reason to have SVA device in the > > > > first place, providing a SW API to turn it all off seems like the > > > > wrong direction. > > > > > > I wouldn't say this is a major reason to have SVA. If we read the > > > history of SVA and papers, people would think easy programming due > > > to data struct sharing between cpu and device, and process space > > > isolation in device would be the major reasons for SVA. SVA also > > > declares it supports zero-copy while zero-copy doesn't necessarily > > > depend on SVA. > > > > Once you have to explicitly make system calls to declare memory under > > IO, you loose all of that. > > > > Since you've asked the app to be explicit about the DMAs it intends to > > do, there is not really much reason to use SVA for those DMAs anymore. > > Let's see a non-SVA case. We are not using SVA, we can have > a memory pool by hugetlb or pin, and app can allocate memory > from this pool, and get stable I/O performance on the memory > from the pool. But device has its separate page table which > is not bound with this process, thus lacking the protection > of process space isolation. Plus, CPU and device are using > different address. So you are relying on the platform to do the SVA for the device? This feels like it goes back to another topic where I felt the SVA setup uAPI should be shared and not buried into every driver's unique ioctls. Having something like this in a shared SVA system is somewhat less strange. Jason