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 D7981C28B20 for ; Fri, 28 Mar 2025 21:09:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2F22E280167; Fri, 28 Mar 2025 17:09:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 27B7B280165; Fri, 28 Mar 2025 17:09:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0F5C1280167; Fri, 28 Mar 2025 17:09:28 -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 D8E09280165 for ; Fri, 28 Mar 2025 17:09:27 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 926E7A9EDF for ; Fri, 28 Mar 2025 21:09:27 +0000 (UTC) X-FDA: 83272200774.19.B188BD5 Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com [209.85.214.171]) by imf15.hostedemail.com (Postfix) with ESMTP id A5820A000C for ; Fri, 28 Mar 2025 21:09:25 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=ly+SA5RB; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf15.hostedemail.com: domain of vishal.moola@gmail.com designates 209.85.214.171 as permitted sender) smtp.mailfrom=vishal.moola@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1743196165; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=hwl4NdWNLA+WiZCnf70iMDLkFwdpvil0W/uJAOBiirY=; b=dVQmbo6m8/1oGtCUiQbAB4zNC9tWZGk5S2PEgSEzdBAahXAM5lu6xMJevV+d7o5hq9nxqM erKWVvmNHy+kOAI30nT4p2LWGo2JjyMBD0tsmQYXgHsyw2HUcTx5cSi+UcnZfEoHB6ER5A g45WEOnJPSLFRRd4Ex0ny32rfz7aFqs= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=ly+SA5RB; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf15.hostedemail.com: domain of vishal.moola@gmail.com designates 209.85.214.171 as permitted sender) smtp.mailfrom=vishal.moola@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743196165; a=rsa-sha256; cv=none; b=vTLIaoOSyQzXVwsvmGV3GKczcpECS/X/KJKY6MgqzLkQ3vm28t3v+lZ6FGdAeZm6QGqHkb SRILlE5kKeQSACIVPm++s/nmmwDR5rVpf+ezyidrll1Cl8Eq4X2bAASlZ9sCSw9HxcM0h1 xSN/e33iuqcS7VaqkRWObkClho1/gs4= Received: by mail-pl1-f171.google.com with SMTP id d9443c01a7336-2264aefc45dso71184195ad.0 for ; Fri, 28 Mar 2025 14:09:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743196164; x=1743800964; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=hwl4NdWNLA+WiZCnf70iMDLkFwdpvil0W/uJAOBiirY=; b=ly+SA5RBult0vf88BcRvVzy310bU5TTt381SqFcqrZj1bdOK6H4dd+K/1FTLm3Mirz 98EATDMaCFAG9jilQ7xh8XifxzE+3mhC7n6KebtE8Z7uN0c5LP50e4rXPKVY6vfTmBXh gFhRv53+cLJ26Xp6bA0U80HI7IzSV35Q7JBaVY3ajTpppIcce/NxZvOkz4ytTWcusRD7 XCqjODN27Bu2BhxR3RmEvca0DV4beXUT43JkQHcSw3uM4KWhtcv1T7IgizanL9EsRpeQ 5eZauiagmuEwKJg4xtPfR2fKrbBF1Gww5TVnp6EPQLqzC1J2kqokdDbx+8bWVLeL/puS ODbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743196164; x=1743800964; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=hwl4NdWNLA+WiZCnf70iMDLkFwdpvil0W/uJAOBiirY=; b=tXIOOjwwITCHH9z/XD9px5/R0FbvTIlVS2fXp7+mpnjEvnQO4Lu0AHkh4Pb9wjCi8H T6ffq9YFpN5b8ENeKLsrUchtmwcgNckpPwf6EEUolxXwg1QRY/8hb4A6pVfhhBjyBOH8 gNOhihnrVzYcXDPWLwFHdBIrviniIKvR4g6LJmtVHZn3NGC9otwKpexzXYVVI6sdzYkY ycbVuHcKdTUuX8WOPqfv02BxGYMI67fbZ77R+ImU5QsMPmH+YzKRh+YAMNf66YnGWQZv F7DzgtXMDsQDNDmjmwKz4H+Alilr1/B/bd2/5dB2KqrzCJw3sXOF3p0A+ok4q4vAdnEO SUgQ== X-Forwarded-Encrypted: i=1; AJvYcCXBmp6D6f1Gy5l3Uxm7tBb5/Ztnec4XukeR1Scs+0cN8Jfu6nCCKndU/pGRYHtxEAqPX5rlpNSgbA==@kvack.org X-Gm-Message-State: AOJu0YxluPnhZfoDnekqRqbMnaUBWK9QsLR0ZpkGOjQ1F1e/GSU2G1jz HbuGVcBrS8QQ2Y6i3KmlO3rDFF5SiwHMjK2QkUjDPNR7cjjwzuSr X-Gm-Gg: ASbGnctODvfVTXFdoVBY00WG0+IKtyr+1xAt8FfKVaY3B0PvBsujgTkajAx7sYwYqad SD8uahsbxtMLNsJ/GN02k/C8ldBY8t9yOorFzXtP9spgbofucKKuTwP2QtOu7i6TTL/ClM4cP6C x7066QpJ9nf4Aps6FKILK8vDFpqJNO8iNhPgbqdN0fgMS/00zSk/+czOyuc4CsoSb0OqfLMU/KT FHPGrKRR9WAn8w0TcqL7TszRuncDoGhbzKPjTA7ycl2UIgueLhkI4o7BO+85ZAnc6I4g/UoFcuJ FDM5OZOMGX+mDhNU2wznIykIAduSehvFErWkQen2j3mxcrlD90N/CHzN7Mqkj7UNSSGrx60LvSI z X-Google-Smtp-Source: AGHT+IHd9fQtVFVVgph9WnMxD+yvA2cH9ftmKIA/aV/HJRnRVCXLI90/TItx7A2zuPaJnIRPAtH+Uw== X-Received: by 2002:a17:903:2ce:b0:220:e5be:29c7 with SMTP id d9443c01a7336-2292f9f64fbmr10191425ad.39.1743196164150; Fri, 28 Mar 2025 14:09:24 -0700 (PDT) Received: from fedora (c-67-164-59-41.hsd1.ca.comcast.net. [67.164.59.41]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2291eee22a2sm23351755ad.81.2025.03.28.14.09.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 28 Mar 2025 14:09:23 -0700 (PDT) Date: Fri, 28 Mar 2025 14:09:20 -0700 From: "Vishal Moola (Oracle)" To: Huan Yang Cc: bingbu.cao@linux.intel.com, Matthew Wilcox , Christoph Hellwig , Gerd Hoffmann , Vivek Kasireddy , Sumit Semwal , Christian =?iso-8859-1?Q?K=F6nig?= , Andrew Morton , Uladzislau Rezki , Shuah Khan , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, opensource.kernel@vivo.com Subject: Re: [RFC PATCH 0/6] Deep talk about folio vmap Message-ID: References: <20250327092922.536-1-link@vivo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250327092922.536-1-link@vivo.com> X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: A5820A000C X-Stat-Signature: f4j4y8xakktpmthfc45kxdmfqp616hoh X-Rspam-User: X-HE-Tag: 1743196165-30609 X-HE-Meta: U2FsdGVkX190rWqI0JVkQIr+/v4SyH+0vbDT/WIAWAcGpZ0/F1amQbiE9oSx8xCg/1e/ZG5Yhh2RqN8bCJdVmVyi0Ri2F3xJBiFYk7MOwFTwyDf3pn/2xiNpSDhB692ZHe1m5W5VmOtmT6mPPrP8UEhd6/ZO+tUmpMbt1+1QV7YB1DLlV7MJAJ3erk8X+8pUjLU0V+tMpYNKJwB8T0p92qdxQBCLoD4VkgmGwGVp0fUvOsx44yABVJYpUAGDSFjyqoK78ioZrPaY9DDkOPQN0V/1Saujbbo39qklwMBPYOV8ui81Tz0WAZd/+Q/z0vePMkT/qlV6kl/pHvcuqbpyH6QhIBUvEPyi+CRJfhDsJnfMv3XXEmn22Sount1Fj1px2HQekrSC5/zoat2ef2fNZOU2AE9fWTuPhOE24ZRCz6eMSU/BzCo2Ck697OH73/iRL7yEXrj84Ff+ikvvIwUDIQv5Q1jqapKY9SjZG7YYr45U6NKYFRiu0gwSDg4WAmKsppg81L4Kwlcd42es5nxzLcjoCrf0vQz/5TGKnefvm8i68Of8J2y3tWxjF8bSZGCHNJFxdkJ7/wp4aNJ5o602kpboVTSUer25Kfl1c6IoMeRgnDXwAYul4/oUpn5Eo5x8klPZXSFPjxH9vQP0I0rUqXW4cPrmVw9F95uQkFlS8eCmS5enS4n1mEUIGADW3v/sKXuk6K1nyvLFrGXHYpWCfBajNdP6inVAIp2lX7+iDqEsADZB85p4Yonj/Ihna2ATG6sx87nkmSA8BbO8XwGGMc7kYTZG8lTHi3xGr+Kn0XZhGimwHOWdxOX+4Z5NxMybtB7r1CdNgu6jilTw0odZTr/NNhr0j8TiDVOOYmyMa+E0pfLjTeKDqsWVm02w8UrXQw02vqw087cD6MYVNSjj8TftD72Xy0uSlwtbqd1lA8WDBVwQ7ULEHTnyIlV3A0LT0Aex6h+Dl1Ls9S8UgMk dX04h6WT lhuFhlBk+ZLCFZId9gLIw4Jfo6X2SvhlxHKtk7hnoHz0tqJMH20RCZ0EYcdRxXUyNXGddpB1m+PJZj40ZZmaboMhhp7xf93bZhg8GsUF2el8hUfyQwQnGJolgkLNXVqRa9Lir2QtSsfb0xHTuSES+qZO7Gdui4LCRjZ8Yp+x+dMgA42woVbu7hDO5Pz7hXOe2KPsnRIEAv6IAS2VfpBufMw3OQdR77czPJRDCdPeEGwVJ/YQDFGjXDo49uD7Cx51ZGsfocfDWtFR1nszWbaVW96FsLXik3uBUvEn1X6p7T71GsG/xdpb4F3SulRlblsjlhYVn8XhboY99Nji27jbl+7hAhCWixxV+vR6WDnxcskoC06ajPMcwANiCblEPbhUpUl9tHzwgJSXThQH+5ldvWr97P9HEaNbRdYtoLV1rqw+23wIfRmj+2/FZmaVmmscJJLInm3FfJefQ6wPydTaO0uUSCs/SeEqvUz+u 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: List-Subscribe: List-Unsubscribe: On Thu, Mar 27, 2025 at 05:28:27PM +0800, Huan Yang wrote: > Bingbu reported an issue in [1] that udmabuf vmap failed and in [2], we > discussed the scenario of folio vmap due to the misuse of vmap_pfn > in udmabuf. > > We reached the conclusion that vmap_pfn prohibits the use of page-based > PFNs: > Christoph Hellwig : 'No, vmap_pfn is entirely for memory not backed by > pages or folios, i.e. PCIe BARs and similar memory. This must not be > mixed with proper folio backed memory.' > > But udmabuf still need consider HVO based folio's vmap, and need fix > vmap issue. This RFC code want to show the two point that I mentioned > in [2], and more deep talk it: > > Point1. simple copy vmap_pfn code, don't bother common vmap_pfn, use by > itself and remove pfn_valid check. > > Point2. implement folio array based vmap(vmap_folios), which can given a > range of each folio(offset, nr_pages), so can suit HVO folio's vmap. > > Patch 1-2 implement point1, and add a test simple set in udmabuf driver. > Patch 3-5 implement point2, also can test it. > > Kasireddy also show that 'another option is to just limit udmabuf's vmap() > to only shmem folios'(This I guess folio_test_hugetlb_vmemmap_optimized > can help.) > > But I prefer point2 to solution this issue, and IMO, folio based vmap still > need. > > Compare to page based vmap(or pfn based), we need split each large folio > into single page struct, this need more large array struct and more longer > iter. If each tail page struct not exist(like HVO), can only use pfn vmap, > but there are no common api to do this. > > In [2], we talked that udmabuf can use hugetlb as the memory > provider, and can give a range use. So if HVO used in hugetlb, each folio's > tail page may freed, so we can't use page based vmap, only can use pfn > based, which show in point1. > > Further more, Folio based vmap only need record each folio(and offset, > nr_pages if range need). For 20MB vmap, page based need 5120 pages(40KB), > 2MB folios only need 10 folio(80Byte). > > Matthew show that Vishal also offered a folio based vmap - vmap_file[3]. > This RFC patch want a range based folio, not only a full folio's map(like > file's folio), to resolve some problem like HVO's range folio vmap. Hmmm, I should've been more communicative, sorry about that. V1 was poorly implemented, and I've had a V2 sitting around that does Exactly what you want. I'll send V2 to the mailing list and you can take a look at it; preferrably you integrate that into this patchset instead (it would make both the udma and vmalloc code much neater). > Please give me more suggestion. > > Test case: > //enable/disable HVO > 1. echo [1|0] > /proc/sys/vm/hugetlb_optimize_vmemmap > //prepare HUGETLB > 2. echo 10 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages > 3. ./udmabuf_vmap > 4. check output, and dmesg if any warn. > > [1] https://lore.kernel.org/all/9172a601-c360-0d5b-ba1b-33deba430455@linux.intel.com/ > [2] https://lore.kernel.org/lkml/20250312061513.1126496-1-link@vivo.com/ > [3] https://lore.kernel.org/linux-mm/20250131001806.92349-1-vishal.moola@gmail.com/ > > Huan Yang (6): > udmabuf: try fix udmabuf vmap > udmabuf: try udmabuf vmap test > mm/vmalloc: try add vmap folios range > udmabuf: use vmap_range_folios > udmabuf: vmap test suit for pages and pfns compare > udmabuf: remove no need code > > drivers/dma-buf/udmabuf.c | 29 +++++++++----------- > include/linux/vmalloc.h | 57 +++++++++++++++++++++++++++++++++++++++ > mm/vmalloc.c | 47 ++++++++++++++++++++++++++++++++ > 3 files changed, 117 insertions(+), 16 deletions(-) > > -- > 2.48.1 >