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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id BD108C43334 for ; Tue, 12 Jul 2022 00:15:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1DAD394002B; Mon, 11 Jul 2022 20:15:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1898B940010; Mon, 11 Jul 2022 20:15:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0790B94002B; Mon, 11 Jul 2022 20:15:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id EB635940010 for ; Mon, 11 Jul 2022 20:15:07 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id B126A20E1B for ; Tue, 12 Jul 2022 00:15:07 +0000 (UTC) X-FDA: 79676527854.21.6CAECD1 Received: from sender4-op-o14.zoho.com (sender4-op-o14.zoho.com [136.143.188.14]) by imf21.hostedemail.com (Postfix) with ESMTP id 294921C006B for ; Tue, 12 Jul 2022 00:15:06 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; t=1657584897; cv=none; d=zohomail.com; s=zohoarc; b=bJmObJhUXPfREMqCN/WvVFaSBUz3AzVlTwIJKfvLDHoe1aG6K7Iqc4ovk/XOOtlgXLTGsjOwF4JoS8ZWQfquvAZ+nspaUKHGAabfjufMaeksl3J0Wma8w3FrjHTrYGL/azYM2wZr1L7giIUz5mvI/OeW1d/maBtAD4yGIyjVZIk= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1657584897; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=fhJVT85aTlBQWQb6yaeXraBInDSuiyuvEmq9JyUyXYE=; b=HJXLnQdePfBzYS5gYvF2NWYq6Ar0h+zlTQeWYGDsmpy47vOMKQ1cguN2NJ3nOFpcdqRWJEYd0V0ewebpw87dq4EmRKZC1Mt1eEv6zcO0Hj50baqOiLSxitRYwkUC33qqZQ05ygR7jv4iKMRhZ2KOt7bR4+5Xp7O8A08iD42DfB0= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=linux.beauty; spf=pass smtp.mailfrom=me@linux.beauty; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1657584897; s=zmail; d=linux.beauty; i=me@linux.beauty; h=Date:Date:From:From:To:To:Cc:Cc:Message-ID:In-Reply-To:References:Subject:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To; bh=fhJVT85aTlBQWQb6yaeXraBInDSuiyuvEmq9JyUyXYE=; b=ht469zLCvWSqlKO3GMKF5L1p8SJlW6uMKUtxZUtAmkO/WlFcm1aMBSqQvNJ/dgUN vTxuNTnejwgRWnlF1T5TDGb3pDxejhjEgsaZYCNzMF3F/15bHdKcnGgUDFjdVU02U6D TZdqG93CB0fZCtau2mX8Ml/V9B1YS81TCUVheAU8= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1657584897026777.3647169706071; Mon, 11 Jul 2022 17:14:57 -0700 (PDT) Date: Tue, 12 Jul 2022 08:14:56 +0800 From: Li Chen To: "Christoph Hellwig" Cc: "Catalin Marinas" , "Will Deacon" , "Rob Herring" , "Frank Rowand" , "Andrew Morton" , "linux-arm-kernel" , "linux-kernel" , "devicetree" , "linux-mm" Message-ID: <181efc24bdd.108279419521615.7697137316951540027@linux.beauty> In-Reply-To: References: <20220711122459.13773-1-me@linux.beauty> <181ee01d384.b809bd01412268.496620746959082770@linux.beauty> Subject: Re: [PATCH 0/4] add struct page and Direct I/O support to reserved memory MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Importance: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1657584907; a=rsa-sha256; cv=pass; b=AQJFTCsaGaugsy53L6lcXaC/FJJND5U9xCimayQ09iPfdfo0TuS61wc8MT8nwvJVGA2y0a d4IQGKrR2jAWqxvStGG1r0748218+Gh/oK9qjpdmxqVenOLcr34YUG0wkOnPIGSxjaSGst 1bBcmLXfZp80LoNAiZ+wM6K8hPZmsfw= ARC-Authentication-Results: i=2; imf21.hostedemail.com; dkim=pass header.d=linux.beauty header.s=zmail header.b=ht469zLC; dmarc=none; spf=pass (imf21.hostedemail.com: domain of me@linux.beauty designates 136.143.188.14 as permitted sender) smtp.mailfrom=me@linux.beauty; arc=pass ("zohomail.com:s=zohoarc:i=1") ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1657584907; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=fhJVT85aTlBQWQb6yaeXraBInDSuiyuvEmq9JyUyXYE=; b=DFxdMbCShWxjCCWyXtKWPcMzHgZA10+QPLsYdEvUeZYO80WUhXuvXlHt55NMtWXnqAMVBg Er3FtVIQmLlhbMSD+rwVVDdeE5AVoR/Qy4zc+n5qP0BjmiG7oEahjq9aZqASRAwE4Xo3c1 SfSZ23oczDSc0PW2fw/OfK8YCTLo4F0= Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=linux.beauty header.s=zmail header.b=ht469zLC; dmarc=none; spf=pass (imf21.hostedemail.com: domain of me@linux.beauty designates 136.143.188.14 as permitted sender) smtp.mailfrom=me@linux.beauty; arc=pass ("zohomail.com:s=zohoarc:i=1") X-Stat-Signature: sxsicgidma4mbnt57ef448bny7qy7gy7 X-Rspamd-Queue-Id: 294921C006B X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1657584906-240199 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: Hi Christoph, ---- On Tue, 12 Jul 2022 00:09:55 +0800 Christoph Hellwig wrote --- > On Tue, Jul 12, 2022 at 12:05:06AM +0800, Li Chen wrote: > > My use case has been stated in the cover letter, but our driver is not ready for upstream yet. > > Which means we can't review the use case. I'd suggest you come back > when you submit your driver. Totally agree, but we plan to start rewriting the code of our video driver in a long time, it has many legacy codes and I need to rewrite a lot of codes to migrate to v4l2. That's why I also submit a sample driver here: to make the review progress easier and don't need reviewers to read video driver codes. > > > With DMA allocator, we can access buffer in kernel space, not userspace, however, this patch > > Take a look at dma_mmap_* on how to map DMA coherent allocations to > usersapce. This is of course easily possible. > Yes, I know them. They take use of remap_pfn_range, which set VM_IO and VM_PFNMAP on vma, so dio is not possible with them. IIUC, if you want to expose the kernel's reserved memory to userspace, it doesn't matter whether the memory came from dma allocator or something else. The point is if they want to get better throughput, they can consider replacing their dma_mmap_* with my reserved_mem_memremap_pages + reserved_mem_dio_mmap. Regards, Li