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 BEFD7C7115B for ; Wed, 18 Jun 2025 06:28:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5586B6B008C; Wed, 18 Jun 2025 02:28:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5093F6B0092; Wed, 18 Jun 2025 02:28:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3F8236B0093; Wed, 18 Jun 2025 02:28:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 2FDD76B008C for ; Wed, 18 Jun 2025 02:28:31 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id CAB29805E0 for ; Wed, 18 Jun 2025 06:28:30 +0000 (UTC) X-FDA: 83567542380.04.BFB9B6D Received: from mail-pg1-f174.google.com (mail-pg1-f174.google.com [209.85.215.174]) by imf02.hostedemail.com (Postfix) with ESMTP id 3CE1B80002 for ; Wed, 18 Jun 2025 06:28:28 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=fkevnObH; spf=pass (imf02.hostedemail.com: domain of lizhe.67@bytedance.com designates 209.85.215.174 as permitted sender) smtp.mailfrom=lizhe.67@bytedance.com; dmarc=pass (policy=quarantine) header.from=bytedance.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750228109; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=mI57uaSGABNj0PlhCXhnWj7DOQSN5+fWjT4KpZNdSHY=; b=L3A7+/Op4F5ygmCDje2MZIEkz0PvgVvUjxwE2Ck7jcmkmCSlIBYd8WONHZT78ZqVsXSl/G hJ0h4xwhmUv8vwv/rET+I2p8MgjD3eeMPU/DVYoAD0QxmIT1C3dPZt034G1I7doI1Zd7yE agp1RZ5NA7aO/1WhYAC92Em+udm4XsE= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=fkevnObH; spf=pass (imf02.hostedemail.com: domain of lizhe.67@bytedance.com designates 209.85.215.174 as permitted sender) smtp.mailfrom=lizhe.67@bytedance.com; dmarc=pass (policy=quarantine) header.from=bytedance.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750228109; a=rsa-sha256; cv=none; b=efVe+hQ5S3C/Dprm+GaX7WeBGBdhMgVOFzOqw/PiLMVrNfvtJHgISosElhRFhvnqUEAq73 y49S0cxztVqdm+LJ/n/n0Hkc/ueO1vqBGFuO5GLl6MXQOnGE+ltwu9GJuTevq14G5YwI7w ickokY24zehf9Vis2sciiIMw56qpxZ8= Received: by mail-pg1-f174.google.com with SMTP id 41be03b00d2f7-b1fd59851baso4302158a12.0 for ; Tue, 17 Jun 2025 23:28:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1750228107; x=1750832907; darn=kvack.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=mI57uaSGABNj0PlhCXhnWj7DOQSN5+fWjT4KpZNdSHY=; b=fkevnObHEK/mtotxciN3rEjViqsr1J0ew/l742+HMu6vS2Bv74pKIvLxFYc2SETbDc kGn6glnY8C5cTOJi19c50DumlKcFVVeQuYwJN+XbHbkVHIeXzAHzE5ONOQr4diqtcpKT HGJTyMPdUHyBIg+YHUpA9WcXk1dZRIXRSIoT0HX8tB8OmvpPxfb+J2ElyNja9YwaGa/2 yXCgxoulwjWbuAX1UoLZDFrlWSuZmsvkgj88VE7ill/y0lBhvP35ogt7TRoaHW4hg56/ ADlbLTpyL9lna5L2sGLiQoXoiy5RZ+YyL4IQwWAb5jxyYkGH5iwtc/aQg1+/NBvY3aXl gS7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750228107; x=1750832907; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=mI57uaSGABNj0PlhCXhnWj7DOQSN5+fWjT4KpZNdSHY=; b=vE2A9GmfZWjWobYNtzGUiQF3rETZ2LsV3OmMssO3sFLjdAE8VtsYOF9Up8oJbiCGEl NjEmPI5/YLW4JEx+xPgfIhuHUZfGNK89U5D/ZgDOvgtF2V2SPBo/iuuPddKOC5S52Zn0 SGsYlICoz4ZLTOeOIu5e/krQm/Y3JQbKDxrlo6IPJwBB9X+mWUKKEo6WQFc4Ggpn1I4v NSfdv8YCz5IP5GE/bGVta1mL0NmKP3haKFC3TFN7o3udizbdsuRKXgVOU3YF8dGysmuh 0xgT5w6LUwsGMwKNTADGuXXpCJNbtqbohE/z+gX+dHt3QUl8hA9WshLEG/0eKFLr4IcG 6K6Q== X-Forwarded-Encrypted: i=1; AJvYcCUoW8q1MAHFVTBDX62IHOuv+C1J0ZiUoFZuJSxZnlmWgEYf9Qy0Qkq0drVOXwk3SowRZwQ8issAog==@kvack.org X-Gm-Message-State: AOJu0YykHmoeCg+LbiTrLlD9+6XUyA14VYuXR1vxNsNKxrUiO/VtGRGW Bmmw82WHv1aMLoT13WO+8Y32T7QvSbr0MBNIZMIhgSygtY3pWAE3D0HP8xqCc12QAbU= X-Gm-Gg: ASbGncuTdMlJ5FKhiaM8QlLw4Nv6azj/OyIAhAU56TepYKxp99ye+RKRm32JZMKllXp jHD+s19lVsAFKjD/zlRuK0FUupJGWFclh9SkAeH8vkssmGWdVxuAJnl/VXXizO//0C0cAL/96yy /p84LPSzjHyWtUoxCAzPwzIZMkNc1gtOC5E3aMztMBXsWPlnb7rCDMasZOJ/3HlBcRS+gxeT5av wIu49PG4ISZ/HwadC5GHF1QhIVVtUDDExsMqAyFmIKH9+D2vSf+RxfxI8XwYtVfzcHOa+Xk4Pxm 2/IzUcClv6x8OB6C0TVr2q2uwrKcGBklrK0Jn+5+Sjob2MhonZd0OPsBml6alSYlYsy3cICNFd8 mW2Rlv2UEgG4o X-Google-Smtp-Source: AGHT+IE+2M9MkPtRgZNvLkNSyl6vr4XBqYCNAnKxfe0Vg46VcdclkjFTQaKK865r2eMg2Tgra0VrYw== X-Received: by 2002:a05:6a21:1512:b0:21e:eb3a:dc04 with SMTP id adf61e73a8af0-21fbd495d28mr24231233637.3.1750228106695; Tue, 17 Jun 2025 23:28:26 -0700 (PDT) Received: from localhost.localdomain ([203.208.189.5]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-b2fe168b971sm10044933a12.58.2025.06.17.23.28.23 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Tue, 17 Jun 2025 23:28:26 -0700 (PDT) From: lizhe.67@bytedance.com To: jgg@ziepe.ca, david@redhat.com Cc: akpm@linux-foundation.org, alex.williamson@redhat.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, lizhe.67@bytedance.com, peterx@redhat.com Subject: Re: [PATCH v4 2/3] gup: introduce unpin_user_folio_dirty_locked() Date: Wed, 18 Jun 2025 14:28:20 +0800 Message-ID: <20250618062820.8477-1-lizhe.67@bytedance.com> X-Mailer: git-send-email 2.45.2 In-Reply-To: <20250617152210.GA1552699@ziepe.ca> References: <20250617152210.GA1552699@ziepe.ca> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 3CE1B80002 X-Rspam-User: X-Rspamd-Server: rspam07 X-Stat-Signature: 63nk69rfe1hk1ady5gnztkzb7wd1pbx1 X-HE-Tag: 1750228108-100333 X-HE-Meta: U2FsdGVkX181zAc6HM5pW0WrPpTEsBvzdANkxjtK3+547f1vuEwmN4LzaK72NRxDTo9YLtTMp8rGvtq/foX+e8YuE+efUnGNBxgPB/bY4JoGrdhhYHUy7As7WZphHQt9Vu28SvvJfeHniXlK4LHis3kzuyr7u62lca27qCWQRDaf/sLzd/pXY7htFD3C0D7CPYRSdTuw++Xs/M3UnJe8F3L8VN9TSaDIId77YN+x35X6M16i/rctfM9+P8tnHHs/9JpJ0wmGK1W7Mjdvuj8vBRe4ym4yn/ZwQxqS3n5bNwkHb0CmzUVKHe2WScd9rvddkpOKgdzaX7jwnzdq/0U2ur2BEXx7AEcW0NB2XYj8+hBYodgcm6ip4px5M1Msn9zoV89MksHVo54TPWthbEgBk4Eo2/aX2q5mfgh4gTnFH/YEbI4lzyFIDwykr2Znxp65M4D+ikKZAJ/WK4SojcbcVKO6WdqImN2p0eILlbrOEcKon/pUHLmQbjBch7DIlLoeLL5p6ChOibKuxwVsWv6YMGuYxzD7gv8bOyJU6tKvUgkUUmY43mRAksYqrygZbe7YnOb8LXUkfGE7i8A+Tf3f3vbpKUkW7GqzZOa43MuwYj4JTICKrJhManwHszbtKQvIBwFkJ77VOnqfqgaBce+4p/3Da1tVQ/QTGuQbYsKwtx1ZhnJPFaiOIA8YB8chmVrmvPu0ldv5JxbhCVDuvGxr7139ozHcJqbngbuWrOZxqO5Q4RPym3x22rMqZCcpiFb13P9JPlcjSs8OmbbN4zrF2xarGMqiWR5fLmcBrzNYivtvPq2DhSg/h89Xo9Ejg/tOk8GJTlSNylmuAB/ks1j7aVFs9ZLkP7+SN7y1P2Wuv4+GlrPNW5DAe8/K0Dwg6IbSKnSDgP/KOMOb4a4ycde5P2ZIN5fIxSwBK98qGpq5GVTu1Y4jjmHxj5fvgwaODl7bwesZD/0hKqOMEplcTqX qmfJiRbN zxtwh1ipVuumGnewRKzSW4AWA7dO6iVOAvqyYgAMolJlPlb/BD5V/mPvnc9cD4jMMU4awY8++aMBN1D7T5oCmmYWHKA== 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 Tue, 17 Jun 2025 12:22:10 -0300, jgg@ziepe.ca wrote: > Weird, but I would not expect this as a general rule, not sure we > should rely on it. > > I would say exported function should not get automatically > inlined. That throws all the kprobes into chaos :\ > > BTW, why can't the other patches in this series just use > unpin_user_page_range_dirty_lock? The way this stuff is supposed to > work is to combine adjacent physical addresses and then invoke > unpin_user_page_range_dirty_lock() on the start page of the physical > range. This is why we have the gup_folio_range_next() which does the > segmentation in an efficient way. > > Combining adjacent physical is basically free math. > > Segmenting to folios in the vfio side doesn't make a lot of sense, > IMHO. > > drivers/vfio/vfio_iommu_type1.c | 35 +++++++++++++++++++++++++++++---- > 1 file changed, 31 insertions(+), 4 deletions(-) > > diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c > index e952bf8bdfab..159ba80082a8 100644 > --- a/drivers/vfio/vfio_iommu_type1.c > +++ b/drivers/vfio/vfio_iommu_type1.c > @@ -806,11 +806,38 @@ static long vfio_unpin_pages_remote(struct vfio_dma *dma, dma_addr_t iova, > bool do_accounting) > { > long unlocked = 0, locked = vpfn_pages(dma, iova, npage); > - long i; > > - for (i = 0; i < npage; i++) > - if (put_pfn(pfn++, dma->prot)) > - unlocked++; > + while (npage) { > + long nr_pages = 1; > + > + if (!is_invalid_reserved_pfn(pfn)) { > + struct page *page = pfn_to_page(pfn); > + struct folio *folio = page_folio(page); > + long folio_pages_num = folio_nr_pages(folio); > + > + /* > + * For a folio, it represents a physically > + * contiguous set of bytes, and all of its pages > + * share the same invalid/reserved state. > + * > + * Here, our PFNs are contiguous. Therefore, if we > + * detect that the current PFN belongs to a large > + * folio, we can batch the operations for the next > + * nr_pages PFNs. > + */ > + if (folio_pages_num > 1) > + nr_pages = min_t(long, npage, > + folio_pages_num - > + folio_page_idx(folio, page)); > + > + unpin_user_folio_dirty_locked(folio, nr_pages, > + dma->prot & IOMMU_WRITE); Are you suggesting that we should directly call unpin_user_page_range_dirty_lock() here (patch 3/3) instead? BTW, it appears that implementing unpin_user_folio_dirty_locked() as an inline function may not be viable for vfio, given that gup_put_folio() is not exported. Thanks, Zhe