Message ID | 20240801104512.4056860-2-link@vivo.com (mailing list archive) |
---|---|
State | Not Applicable |
Headers |
Received: from sy.mirrors.kernel.org ([147.75.48.161]) by linuxtv.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from <linux-media+bounces-15688-patchwork=linuxtv.org@vger.kernel.org>) id 1sZTJV-0003sl-1S for patchwork@linuxtv.org; Thu, 01 Aug 2024 10:45:46 +0000 Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id CE944B22F7C for <patchwork@linuxtv.org>; Thu, 1 Aug 2024 10:45:38 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id B0CA7183CC8; Thu, 1 Aug 2024 10:45:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=vivo.com header.i=@vivo.com header.b="VGGU+g+9" X-Original-To: linux-media@vger.kernel.org Received: from APC01-PSA-obe.outbound.protection.outlook.com (mail-psaapc01on2074.outbound.protection.outlook.com [40.107.255.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 794DB61FD7; Thu, 1 Aug 2024 10:45:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=40.107.255.74 ARC-Seal: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722509132; cv=fail; b=PtRiRcNdimBv5CscXYz/xJ2oTlsGyMWafuOCeDLY5yPNUUJcC7zItfesuGvHEHRGlkd4BBte9vC7pmoqFMcLsJMg7DR18fjjkEW8FbFOPFL+bshWEk7TSvlZLvBhvscXo2Tjcf/CfYYuAQtIhewxNAOpxxQuoDBZEpI5/VCej58= ARC-Message-Signature: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722509132; c=relaxed/simple; bh=HgVhmaIfAU3jB57kB2SsDsz2RI22oygtxcyGPgPaMzo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: Content-Type:MIME-Version; b=C4M4Sod9iOEwCB0gm6F3PhWvwsqtVH0IWDuJL2jmdvsDyUucDnTT/jK8BXwUYJJg1lnlj8scAYaZe2EURYh+APRDS2hTTt1iMMDQ9HptstSDeUGJqLTjpHiCZOlPcINEGCcbKomD+JFAP4fiUt+tySGTvNbHjzTZsWf/18lC0cY= ARC-Authentication-Results: i=2; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=vivo.com; spf=pass smtp.mailfrom=vivo.com; dkim=pass (2048-bit key) header.d=vivo.com header.i=@vivo.com header.b=VGGU+g+9; arc=fail smtp.client-ip=40.107.255.74 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=vivo.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=vivo.com ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=LOqJsYIpbgd4tAxIhlM3/+mxWt06akfggV6v5wfWd+WOV2J5nNgGlM4Lk2Gu4TSfrSsY5XLVtEl4UcROy7Wjn6C5PXvyCo9iOzkKy6mnE7z8BgEyJ2IAkpq18s1t8fz+EKSRa0FjI4Sz75MRXaQ5tQshPlLoOsKFJc2c0wrOojcUFm+8hTcCpSdClZgSYyAEcxbT12yzZglxx/6gUm5F5nDErxDq+I/jg36x6VcCDQC9cHvU+1L5oWXNVaouwgXCtWjJk819zNj1uPEtVOs5vWsrttmpgWiE6LssRC9OmbMRusCGTszGjNfHAzPxpHmI3zkB7SNtygWdisEXdOSKpg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=XGNxavGBonMGVhAMEsLOUEdKXKTo0xNEi6YQPpzYGHg=; b=JK/TxzeLwHWmjmfZubCInhmRroTLYZslzX6NWDZHZ/nP1RFN8/nyC+yQdPKMG/gYVwGVb8OjyQvh25b1ekKz0geMTkspsfBMUV2V95kAwXYO/AVjytk/r4vVZgtNKgQwXvOYsuOPS1rdG+jynC+4zaknuQtL/U2zckGYrmyZ22+M8ycyxOvY340JMfRySm7bj6Jqgdnq03asHoIK1s/uwLA86I4h+DqoP5MRrlQ2M/niB1OxEoPsH5wJnZYpbkYAEJAcq/KWsgTBQEXFDOlHz5UlD+d5lgmPHAzjq4HwriqfGxu/GrzBCHymmO5GIgLf1jkV1rd++iiDFZupoYZTmw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=vivo.com; dmarc=pass action=none header.from=vivo.com; dkim=pass header.d=vivo.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vivo.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XGNxavGBonMGVhAMEsLOUEdKXKTo0xNEi6YQPpzYGHg=; b=VGGU+g+9FesUybzCztGfDy+gdjd6yhSm1z1hVOFGHs8tNYZaVnHi1+T8Zlhjx79nZwxH/vFQ/liJIdi2MJdNfGATqQpw7ck/cagQfjEtuhAraA8TsgYtDb90n2IUarARwWIet2N0AoMlMaEMwx5PrGXff3BJFDJ/K5ypMPRRpbzMSQ4y0wkA0pf7tlBE2f2BDnEGNfkiQRE8GTkaUBCYR+zwJITrkNPqpHx7r6La3hwawVSHIoZUhF/LZeQuvr9+3Wdr/VhuTDgJcxkasu3A3nBogb+L2W8RNgPPT5tLw4xBpHfgaze7FspoYHCIrSKOhXEfBUO6e+0B8oM6h9JBTA== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=vivo.com; Received: from PUZPR06MB5676.apcprd06.prod.outlook.com (2603:1096:301:f8::10) by SEZPR06MB6304.apcprd06.prod.outlook.com (2603:1096:101:10d::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7807.28; Thu, 1 Aug 2024 10:45:25 +0000 Received: from PUZPR06MB5676.apcprd06.prod.outlook.com ([fe80::a00b:f422:ac44:636f]) by PUZPR06MB5676.apcprd06.prod.outlook.com ([fe80::a00b:f422:ac44:636f%4]) with mapi id 15.20.7828.021; Thu, 1 Aug 2024 10:45:25 +0000 From: Huan Yang <link@vivo.com> To: Gerd Hoffmann <kraxel@redhat.com>, Sumit Semwal <sumit.semwal@linaro.org>, =?utf-8?q?Christian_K=C3=B6nig?= <christian.koenig@amd.com>, dri-devel@lists.freedesktop.org, linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org, linux-kernel@vger.kernel.org Cc: opensource.kernel@vivo.com, Huan Yang <link@vivo.com> Subject: [PATCH 1/5] udmabuf: cancel mmap page fault, direct map it Date: Thu, 1 Aug 2024 18:45:05 +0800 Message-ID: <20240801104512.4056860-2-link@vivo.com> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20240801104512.4056860-1-link@vivo.com> References: <20240801104512.4056860-1-link@vivo.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SG2PR06CA0209.apcprd06.prod.outlook.com (2603:1096:4:68::17) To PUZPR06MB5676.apcprd06.prod.outlook.com (2603:1096:301:f8::10) Precedence: bulk X-Mailing-List: linux-media@vger.kernel.org List-Id: <linux-media.vger.kernel.org> List-Subscribe: <mailto:linux-media+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-media+unsubscribe@vger.kernel.org> MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PUZPR06MB5676:EE_|SEZPR06MB6304:EE_ X-MS-Office365-Filtering-Correlation-Id: d0386eab-960b-458b-c3b7-08dcb2170d26 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|52116014|366016|376014|38350700014; X-Microsoft-Antispam-Message-Info: /5svspaDkFltQhYXYqp7RLcVKThBmMv583X3nQq3JRH2Jp5ekPWXmDzpNVkn0Ks1McA4337l8nUZjrDr5pfKfg28uywONrRgtMakCpTMu5KFVGA9wLQB6E/gcid5Ld/ZHUWSAfEVz1bZmuC2r+vwLu26a26JVSn/+5Vqtvv0w4MKbLxCdLPQ2S+eJz2GQ70ZsTAL0XpB+fihLXi1gIhkLzqDIgd0oYt4l9GKxwh0ghSO7vXJ0cvbh37S9bezHs1DJ/iwrITFItTV4noVVLeu9y67gb5PFadBM4gID9kNPgBJ54MFJ0iCkqVgaR7Tr2Kpi8glmEV6Lhs34ni33+urfnlsCPCz9eaCpLFPdXzHylkCa/AreD8r2wjD1IGYSdnR6M0U7ojTWcQunsG5Y9hAuu4aLOpW2hEWjre8YulnKXT2rNfdwCam8IqlXQ98UHFbgL4Fdex3oAI5wh/7KMmmNDUBTJ1GIkZVjlzibxuH0/QifdtqbXLWW8Lll5YDxQxFNB0s2b9PI9kwiohi8eIJzBAZ4lTWWUm2q9Zy9p0kMeGhd0Q4rVbPW4QpgbY1kZQpAquoCXhh6VTCWaNZntHMYcYxxXUmyhIVmvU8RF2LgIJy3oPA5+KKAapHR500kaXb2st35suiJ/3sSECDZgXP+JWKmZxNK/rQkLtgVXPWYFW2l6Ht0jOZP6yPHj/GhYh8pVV+4ME0Ot78voz6s5WP+hGC19AmTZSeMzkacOKrNfitIp+6q+gYtDQubpsBPhtC7gUISvtRfATNHRfuA5z5w1pvNhW1ik9SCyH6LPj8mTCKlzpQp7xtIgZ1AGhfms/2P2Or9THrU8ikGUNwpvP4a8mPAVBUED8AqTjtm6cfkLJxVvIjmupzfkCEPflc5SM1JGeRr8gPLf7RMt3hKzYBObLFW+4GA3FsvWPe8SPOtADaAY2ECcJdxMDH8sMp4gUlaTBvJ67UuDS20QpLGjaeePv07vhTK457BJ6uzxduxpa1VrYYR/CeS/z1FpqezHvbBZLgE69OMj84uJIuBV04j7WjoWkXkP9xLjMg4G8zQRaQkVB0wnNKeQQraEkjmxjNfdApopNy+RwRbEuuqJ8PlBWfPTmPHWdCWo1NjJsNed6yM7KKcnxY+4dY2kVwXFjUCaDx6iclMX+09g7/gcKS87eHnkb9DdXi1rfVyUFqNY98ep9U8Nkiv9CJ5fBQ2rSyUmKKzT9Xap9/aov88unt+gx9YpZsCbksAHg+PQ57YikKmcwYDOrMJ+2zfKfDSNrLze3HkQKJozIyrWiUX83y0rmj7tcD6XhGuVh01Gfq6vHk+DKx/YiAJWaXl2scJf8y0h8gLbs0o6WlPAkYva7Ix4K0DQ/ar1glYrNcgLmlesEPCV5r1co5yyfw325IBp02JqYKzS+XD4ilIzDB0B4pFg== X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PUZPR06MB5676.apcprd06.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(52116014)(366016)(376014)(38350700014);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 8kqGCeGnIEIkdHDDO3gevumGfRzRMwCV2aiVGxLVsroI8E794pGePXZIxuTghzwtZgN1OXU9t/NbD6YLyRhK/L1CxpDiNWM4iryKYKdvO4Mv6/PWy8DFVwoKQX/vEwOMtV845TzqBCCTi1nt0Dg7omFboLqPip9UjI75mzhGs3ZhlUf1+ToM3ltMA1cJidCPxaBnhHST62OpDkKFNotCuEosro/mLf5CJ4Q+jV01CO5Hv3NE+3/+OMEMUQQfJaQgjg4qGPnCXEI7i/9t3kqy82XtmSeX8yewPQwNlh9sRj/VkxEgY7exYc++GqDFSkpM/gs+BMYg1+55U2hS4HwjZpCzOUhznqx155V/Vl8pr3DeMs0IwmDfDvuG84mSRcPj0vixyUe1rx2EzEiuJLwnbJJysE2Lxb+Zr3K8+1eGEpkkEWnMIqbflr29w/nivsGg/I3nX7Qvaj2WFY2diToO7SgVZpTiOvvlV/S7ZJLmPSWK9Js8HQebpVfz5vomiB7wP7f133UaL9kK6NlxFDLjiMlY8S0kufAXQJOthdvuLzxQeeHOwo3VQuGF8cVAsI8PdjBZHE+eyEVvqbxDZKdTmvqukByUOK0uG4UVOWicfVqHqMA3n0pGokuOPeo2f8klIrIQQ9DU4vZICCqEeqSuOZsEf+GPWpEwnEBCsizb+JmBVMygtJRv4Y/xMiHVfyNm67plmTVEGFKAG822c7p7uBqDcGJ3aPxvBw16U5qzUfKbt64ijG8Vukn/tRlTBgs3Z4m8T4xztoBkHtzwdLgdXOWB2jiGT6NlyQQXgvVR8f2VNjmTNuXL6m02vOWGQ9Kkk8Re25s4XD8iJ7HXbsI/y/rtV3fct1zXzT9yrZlYI+xAkMyExxY4jH4WeWxp0qvt05FifLo9ZAYkK9HfjI0GVfVR8uGojoT7MC2SAA2zQWzurzapnMV/rIomqoDmdHQBfDQLA4k3mrP2lUfjAO08TiFRyux+N39+E6Td+/kAO5TmKPBzUAdqNInzNHd899hGbsnhVnioBYD9oQuC602fUleXq04u3IbMEa+VAaJf9SkVTHErOzSVHclgScasPbsuOJZXRhi/g2K2RE6WLNLMclQ+rr5bZ64/BhpSg31HFkM9j9MlXEEGYarw3vW9RRv1gjBHM5f5DuYBrYRsDaJ+fDSLO8H59qYaTAwuaKE4fraZwbDNkcPTQmYdRB1MYVLLxlWrZfe+vTNmGU7zG51PbiUvdiMQBXVRaSJQcX2tK3iBp2jboD99YrCht4XZQMbVIWI8PQXuQ8LqOHl5OfiUO66uLTSmjScYFDuSJr91wa06zUbt9c6P8853mYw+uOHVXzxe1vyM7JekFM3ztvMPjBL3JxROFZsXwbCbBXLU6nLSy4fHZVulIzhFgA/+6C0ntHO8MwsuSwX4OVs/xYKhASGVauJlrEYGpNaG8Da5VXHFVRRPcTqMxQE+hmKjLwnHCO+zMyP6INQbYOEOCYSCQA32W5aBwryFpoeRYUK5/w7eIxNyc2m62HOJ/ecUHmSEJYMPd9FIQEc2zWR6W2k+zRPd7DcFNiH2CBdeePw6bhdugW1FImu+uVxoQhOhJUF1 X-OriginatorOrg: vivo.com X-MS-Exchange-CrossTenant-Network-Message-Id: d0386eab-960b-458b-c3b7-08dcb2170d26 X-MS-Exchange-CrossTenant-AuthSource: PUZPR06MB5676.apcprd06.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Aug 2024 10:45:25.6025 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 923e42dc-48d5-4cbe-b582-1a797a6412ed X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: OAMxMoTh7hW0Q4mVpDeW45Uu/UyFDm0fobl7BIQvStaqUD0nwihqxZ/uQZ9u/YDqdAk8TYpzyRQeCsBBkt7KUg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SEZPR06MB6304 X-LSpam-Score: -6.3 (------) X-LSpam-Report: No, score=-6.3 required=5.0 tests=ARC_SIGNED=0.001,ARC_VALID=-0.1,BAYES_00=-1.9,DKIM_SIGNED=0.1,DKIM_VALID=-0.1,DKIM_VALID_AU=-0.1,DMARC_PASS=-0.001,HEADER_FROM_DIFFERENT_DOMAINS=0.5,MAILING_LIST_MULTI=-1,RCVD_IN_VALIDITY_CERTIFIED=-3,RCVD_IN_VALIDITY_RPBL=1.31,RCVD_IN_VALIDITY_SAFE=-2,SPF_HELO_NONE=0.001,SPF_PASS=-0.001 autolearn=ham autolearn_force=no |
Series | udmbuf bug fix and some improvements | |
Commit Message
Huan Yang
Aug. 1, 2024, 10:45 a.m. UTC
The current udmabuf mmap uses a page fault mechanism to populate the vma.
However, the current udmabuf has already obtained and pinned the folio
upon completion of the creation.This means that the physical memory has
already been acquired, rather than being accessed dynamically. The
current page fault method only saves some page table memory.
As a result, the page fault mechanism has lost its purpose as a demanding
page. Due to the fact that page fault requires trapping into kernel mode
and filling in when accessing the corresponding virtual address in mmap,
this means that user mode access to virtual addresses needs to trap into
kernel mode.
Therefore, when creating a large size udmabuf, this represents a
considerable overhead.
Therefore, the current patch removes the page fault method of mmap and
instead fills it directly when mmap is triggered.
Signed-off-by: Huan Yang <link@vivo.com>
---
drivers/dma-buf/udmabuf.c | 70 ++++++++++++++++++++++-----------------
1 file changed, 39 insertions(+), 31 deletions(-)
Comments
Am 01.08.24 um 12:45 schrieb Huan Yang: > The current udmabuf mmap uses a page fault mechanism to populate the vma. > > However, the current udmabuf has already obtained and pinned the folio > upon completion of the creation.This means that the physical memory has > already been acquired, rather than being accessed dynamically. The > current page fault method only saves some page table memory. > > As a result, the page fault mechanism has lost its purpose as a demanding > page. Due to the fact that page fault requires trapping into kernel mode > and filling in when accessing the corresponding virtual address in mmap, > this means that user mode access to virtual addresses needs to trap into > kernel mode. > > Therefore, when creating a large size udmabuf, this represents a > considerable overhead. > > Therefore, the current patch removes the page fault method of mmap and > instead fills it directly when mmap is triggered. > > Signed-off-by: Huan Yang <link@vivo.com> > --- > drivers/dma-buf/udmabuf.c | 70 ++++++++++++++++++++++----------------- > 1 file changed, 39 insertions(+), 31 deletions(-) > > diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c > index 047c3cd2ceff..d69aeada7367 100644 > --- a/drivers/dma-buf/udmabuf.c > +++ b/drivers/dma-buf/udmabuf.c > @@ -38,36 +38,39 @@ struct udmabuf_folio { > struct list_head list; > }; > > -static vm_fault_t udmabuf_vm_fault(struct vm_fault *vmf) > -{ > - struct vm_area_struct *vma = vmf->vma; > - struct udmabuf *ubuf = vma->vm_private_data; > - pgoff_t pgoff = vmf->pgoff; > - unsigned long pfn; > - > - if (pgoff >= ubuf->pagecount) > - return VM_FAULT_SIGBUS; > - > - pfn = folio_pfn(ubuf->folios[pgoff]); > - pfn += ubuf->offsets[pgoff] >> PAGE_SHIFT; > - > - return vmf_insert_pfn(vma, vmf->address, pfn); > -} > - > -static const struct vm_operations_struct udmabuf_vm_ops = { > - .fault = udmabuf_vm_fault, > -}; > +static struct sg_table *get_sg_table(struct device *dev, struct dma_buf *buf, > + enum dma_data_direction direction); > > static int mmap_udmabuf(struct dma_buf *buf, struct vm_area_struct *vma) > { > struct udmabuf *ubuf = buf->priv; > + struct sg_table *table = ubuf->sg; > + unsigned long addr = vma->vm_start; > + struct sg_page_iter piter; > + int ret; > > if ((vma->vm_flags & (VM_SHARED | VM_MAYSHARE)) == 0) > return -EINVAL; > > - vma->vm_ops = &udmabuf_vm_ops; > - vma->vm_private_data = ubuf; > - vm_flags_set(vma, VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP); > + if (!table) { > + table = get_sg_table(NULL, buf, 0); > + if (IS_ERR(table)) > + return PTR_ERR(table); > + ubuf->sg = table; > + } > + > + for_each_sgtable_page(table, &piter, vma->vm_pgoff) { That might not work correctly. We intentionally remove the pages from the sgtable when it is shared between devices. Additional to that the sgtable is *not* a page container, but rather a DMA address container. So that here is also a rather bad idea from the design side. Regards, Christian. > + struct page *page = sg_page_iter_page(&piter); > + > + ret = remap_pfn_range(vma, addr, page_to_pfn(page), PAGE_SIZE, > + vma->vm_page_prot); > + if (ret) > + return ret; > + addr += PAGE_SIZE; > + if (addr >= vma->vm_end) > + return 0; > + } > + > return 0; > } > > @@ -126,6 +129,10 @@ static struct sg_table *get_sg_table(struct device *dev, struct dma_buf *buf, > sg_set_folio(sgl, ubuf->folios[i], PAGE_SIZE, > ubuf->offsets[i]); > > + // if dev is NULL, no need to sync. > + if (!dev) > + return sg; > + > ret = dma_map_sgtable(dev, sg, direction, 0); > if (ret < 0) > goto err_map; > @@ -206,20 +213,21 @@ static int begin_cpu_udmabuf(struct dma_buf *buf, > { > struct udmabuf *ubuf = buf->priv; > struct device *dev = ubuf->device->this_device; > - int ret = 0; > + struct sg_table *sg; > > - if (!ubuf->sg) { > - ubuf->sg = get_sg_table(dev, buf, direction); > - if (IS_ERR(ubuf->sg)) { > - ret = PTR_ERR(ubuf->sg); > - ubuf->sg = NULL; > - } > - } else { > + if (ubuf->sg) { > dma_sync_sg_for_cpu(dev, ubuf->sg->sgl, ubuf->sg->nents, > direction); > + return 0; > } > > - return ret; > + sg = get_sg_table(dev, buf, direction); > + if (IS_ERR(sg)) > + return PTR_ERR(sg); > + > + ubuf->sg = sg; > + > + return 0; > } > > static int end_cpu_udmabuf(struct dma_buf *buf,
在 2024/8/1 18:50, Christian König 写道: > Am 01.08.24 um 12:45 schrieb Huan Yang: >> The current udmabuf mmap uses a page fault mechanism to populate the >> vma. >> >> However, the current udmabuf has already obtained and pinned the folio >> upon completion of the creation.This means that the physical memory has >> already been acquired, rather than being accessed dynamically. The >> current page fault method only saves some page table memory. >> >> As a result, the page fault mechanism has lost its purpose as a >> demanding >> page. Due to the fact that page fault requires trapping into kernel mode >> and filling in when accessing the corresponding virtual address in mmap, >> this means that user mode access to virtual addresses needs to trap into >> kernel mode. >> >> Therefore, when creating a large size udmabuf, this represents a >> considerable overhead. >> >> Therefore, the current patch removes the page fault method of mmap and >> instead fills it directly when mmap is triggered. >> >> Signed-off-by: Huan Yang <link@vivo.com> >> --- >> drivers/dma-buf/udmabuf.c | 70 ++++++++++++++++++++++----------------- >> 1 file changed, 39 insertions(+), 31 deletions(-) >> >> diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c >> index 047c3cd2ceff..d69aeada7367 100644 >> --- a/drivers/dma-buf/udmabuf.c >> +++ b/drivers/dma-buf/udmabuf.c >> @@ -38,36 +38,39 @@ struct udmabuf_folio { >> struct list_head list; >> }; >> -static vm_fault_t udmabuf_vm_fault(struct vm_fault *vmf) >> -{ >> - struct vm_area_struct *vma = vmf->vma; >> - struct udmabuf *ubuf = vma->vm_private_data; >> - pgoff_t pgoff = vmf->pgoff; >> - unsigned long pfn; >> - >> - if (pgoff >= ubuf->pagecount) >> - return VM_FAULT_SIGBUS; >> - >> - pfn = folio_pfn(ubuf->folios[pgoff]); >> - pfn += ubuf->offsets[pgoff] >> PAGE_SHIFT; >> - >> - return vmf_insert_pfn(vma, vmf->address, pfn); >> -} >> - >> -static const struct vm_operations_struct udmabuf_vm_ops = { >> - .fault = udmabuf_vm_fault, >> -}; >> +static struct sg_table *get_sg_table(struct device *dev, struct >> dma_buf *buf, >> + enum dma_data_direction direction); >> static int mmap_udmabuf(struct dma_buf *buf, struct >> vm_area_struct *vma) >> { >> struct udmabuf *ubuf = buf->priv; >> + struct sg_table *table = ubuf->sg; >> + unsigned long addr = vma->vm_start; >> + struct sg_page_iter piter; >> + int ret; >> if ((vma->vm_flags & (VM_SHARED | VM_MAYSHARE)) == 0) >> return -EINVAL; >> - vma->vm_ops = &udmabuf_vm_ops; >> - vma->vm_private_data = ubuf; >> - vm_flags_set(vma, VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP); >> + if (!table) { >> + table = get_sg_table(NULL, buf, 0); >> + if (IS_ERR(table)) >> + return PTR_ERR(table); >> + ubuf->sg = table; >> + } >> + >> + for_each_sgtable_page(table, &piter, vma->vm_pgoff) { > > That might not work correctly. We intentionally remove the pages from > the sgtable when it is shared between devices. > > Additional to that the sgtable is *not* a page container, but rather a > DMA address container. So that here is also a rather bad idea from the > design side. Sorry for that and patch 1 3 4's ops. I was not aware of this before. All idea to do this in mmap/vmap is just like system_heap and any other heaps that I learned. But well to learn it. BTW, sgtable is a wrong idea to maintain page, maybe we need to both setup page's array(order 0 page), and folio's array(only the folio, use for unpin)? Or else, mapping page to vm_off and vma solely through folio's array is quite challenging. Moreover, even in this way, the memory overhead is smaller than the current unpin list. Thanks for your correct.:) > > Regards, > Christian. > >> + struct page *page = sg_page_iter_page(&piter); >> + >> + ret = remap_pfn_range(vma, addr, page_to_pfn(page), PAGE_SIZE, >> + vma->vm_page_prot); >> + if (ret) >> + return ret; >> + addr += PAGE_SIZE; >> + if (addr >= vma->vm_end) >> + return 0; >> + } >> + >> return 0; >> } >> @@ -126,6 +129,10 @@ static struct sg_table *get_sg_table(struct >> device *dev, struct dma_buf *buf, >> sg_set_folio(sgl, ubuf->folios[i], PAGE_SIZE, >> ubuf->offsets[i]); >> + // if dev is NULL, no need to sync. >> + if (!dev) >> + return sg; >> + >> ret = dma_map_sgtable(dev, sg, direction, 0); >> if (ret < 0) >> goto err_map; >> @@ -206,20 +213,21 @@ static int begin_cpu_udmabuf(struct dma_buf *buf, >> { >> struct udmabuf *ubuf = buf->priv; >> struct device *dev = ubuf->device->this_device; >> - int ret = 0; >> + struct sg_table *sg; >> - if (!ubuf->sg) { >> - ubuf->sg = get_sg_table(dev, buf, direction); >> - if (IS_ERR(ubuf->sg)) { >> - ret = PTR_ERR(ubuf->sg); >> - ubuf->sg = NULL; >> - } >> - } else { >> + if (ubuf->sg) { >> dma_sync_sg_for_cpu(dev, ubuf->sg->sgl, ubuf->sg->nents, >> direction); >> + return 0; >> } >> - return ret; >> + sg = get_sg_table(dev, buf, direction); >> + if (IS_ERR(sg)) >> + return PTR_ERR(sg); >> + >> + ubuf->sg = sg; >> + >> + return 0; >> } >> static int end_cpu_udmabuf(struct dma_buf *buf, >
diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c index 047c3cd2ceff..d69aeada7367 100644 --- a/drivers/dma-buf/udmabuf.c +++ b/drivers/dma-buf/udmabuf.c @@ -38,36 +38,39 @@ struct udmabuf_folio { struct list_head list; }; -static vm_fault_t udmabuf_vm_fault(struct vm_fault *vmf) -{ - struct vm_area_struct *vma = vmf->vma; - struct udmabuf *ubuf = vma->vm_private_data; - pgoff_t pgoff = vmf->pgoff; - unsigned long pfn; - - if (pgoff >= ubuf->pagecount) - return VM_FAULT_SIGBUS; - - pfn = folio_pfn(ubuf->folios[pgoff]); - pfn += ubuf->offsets[pgoff] >> PAGE_SHIFT; - - return vmf_insert_pfn(vma, vmf->address, pfn); -} - -static const struct vm_operations_struct udmabuf_vm_ops = { - .fault = udmabuf_vm_fault, -}; +static struct sg_table *get_sg_table(struct device *dev, struct dma_buf *buf, + enum dma_data_direction direction); static int mmap_udmabuf(struct dma_buf *buf, struct vm_area_struct *vma) { struct udmabuf *ubuf = buf->priv; + struct sg_table *table = ubuf->sg; + unsigned long addr = vma->vm_start; + struct sg_page_iter piter; + int ret; if ((vma->vm_flags & (VM_SHARED | VM_MAYSHARE)) == 0) return -EINVAL; - vma->vm_ops = &udmabuf_vm_ops; - vma->vm_private_data = ubuf; - vm_flags_set(vma, VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP); + if (!table) { + table = get_sg_table(NULL, buf, 0); + if (IS_ERR(table)) + return PTR_ERR(table); + ubuf->sg = table; + } + + for_each_sgtable_page(table, &piter, vma->vm_pgoff) { + struct page *page = sg_page_iter_page(&piter); + + ret = remap_pfn_range(vma, addr, page_to_pfn(page), PAGE_SIZE, + vma->vm_page_prot); + if (ret) + return ret; + addr += PAGE_SIZE; + if (addr >= vma->vm_end) + return 0; + } + return 0; } @@ -126,6 +129,10 @@ static struct sg_table *get_sg_table(struct device *dev, struct dma_buf *buf, sg_set_folio(sgl, ubuf->folios[i], PAGE_SIZE, ubuf->offsets[i]); + // if dev is NULL, no need to sync. + if (!dev) + return sg; + ret = dma_map_sgtable(dev, sg, direction, 0); if (ret < 0) goto err_map; @@ -206,20 +213,21 @@ static int begin_cpu_udmabuf(struct dma_buf *buf, { struct udmabuf *ubuf = buf->priv; struct device *dev = ubuf->device->this_device; - int ret = 0; + struct sg_table *sg; - if (!ubuf->sg) { - ubuf->sg = get_sg_table(dev, buf, direction); - if (IS_ERR(ubuf->sg)) { - ret = PTR_ERR(ubuf->sg); - ubuf->sg = NULL; - } - } else { + if (ubuf->sg) { dma_sync_sg_for_cpu(dev, ubuf->sg->sgl, ubuf->sg->nents, direction); + return 0; } - return ret; + sg = get_sg_table(dev, buf, direction); + if (IS_ERR(sg)) + return PTR_ERR(sg); + + ubuf->sg = sg; + + return 0; } static int end_cpu_udmabuf(struct dma_buf *buf,