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 F0D53C001DC for ; Wed, 26 Jul 2023 16:45:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7C1546B007B; Wed, 26 Jul 2023 12:45:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7718A8D0001; Wed, 26 Jul 2023 12:45:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 639646B007E; Wed, 26 Jul 2023 12:45:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 51C356B007B for ; Wed, 26 Jul 2023 12:45:09 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 17E92402F6 for ; Wed, 26 Jul 2023 16:45:09 +0000 (UTC) X-FDA: 81054337938.29.25E0E0A Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf16.hostedemail.com (Postfix) with ESMTP id C658D18001A for ; Wed, 26 Jul 2023 16:45:05 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=MeDYCY3T; spf=none (imf16.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1690389907; 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=ffylz1uSDobu0cDe/+ol0i31EM3nl1BynfNdms0slZc=; b=xy484tJdfAigymorSUluaLuFYnZi9/ugNTV7dkK6lbzKxucVtWxIYlAZIicLhkz+PvbO5n BVPL77q6aH2OY584T7EzZgqlBl3lfh6zWr0VMOc9zD+V9TOvVtIcZYPAIsqdXm808BMejS LCEvPo1ZY4mS6K0DqrKb+PmBoE251/0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1690389907; a=rsa-sha256; cv=none; b=HH9LM9cLZPSSz3JORN7xT8WO2j8P6M1md0yLqExSufvYnO/aw78jsSeKFT4cDdzswxfWRV 350q9kYb7GQyPTYLrcH4WaLt+hwDAmn1X+AVnVMVZ0mzpIb562U0yI4bVgQ0w32rXHWoEV uz4HO1kkfeXf9SPyxnoY0iHKq/VRJEE= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=MeDYCY3T; spf=none (imf16.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=ffylz1uSDobu0cDe/+ol0i31EM3nl1BynfNdms0slZc=; b=MeDYCY3TCPK1hNuburzA798uN2 9fiomyfW0Yl8idOiy2Fr6RaeMcXeMKgMKCzfABamLPZSJsaXqe3lflR3Ao8XJo7hv6RCyktjKGyNv F6D7dBbE4LpEZIOwos7xPVBZzDFgdP2S3Aj5AZ5lYCdUv0/WUulUNCoUb/u+Klv/SwKIUsuCXYrWK OJdfTymAd49aKh3IfJEl38VXhyyfuT1vteFdlLaMatdLzQsf4HIiusFz+9iKgQ3We/KAU4Qfz/KFB T0TDOyDsr3A6HmoVUVuZInrJX4ZoAZgaPzqCGiEDW41zFd/KG/+zFviUe2XV//jvJYk7ZdL7N7Lnx eM9Ct09w==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qOhd4-006f6o-Tm; Wed, 26 Jul 2023 16:44:50 +0000 Date: Wed, 26 Jul 2023 17:44:50 +0100 From: Matthew Wilcox To: Yu Zhao Cc: Ryan Roberts , Andrew Morton , Yin Fengwei , David Hildenbrand , Yang Shi , "Huang, Ying" , Zi Yan , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v3 2/3] mm: Implement folio_remove_rmap_range() Message-ID: References: <20230720112955.643283-1-ryan.roberts@arm.com> <20230720112955.643283-3-ryan.roberts@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: C658D18001A X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: 4ro8513rwpqgukd4pmdz13zj1hd3bgu1 X-HE-Tag: 1690389905-720888 X-HE-Meta: U2FsdGVkX1/YicGKwDQUczs5vrkVsAhMnIRp1wKZm5N0Wkc/NHNXWhTnq3pBQSJdy3blyS8/nX4ktOm4z88coNVrRnaFw8ipzu529nvwSv5XBWuAYUThQxo9fN6RYFWQ2RLGQwHndpEW1agDH+M70StiYbNZFxHrvtUwpue0PxOESojRvRZ6fC6VlSWFUNXQvQXKnKszhyfQLzQ2oBXtfoOwl3dKx9GUCjJ2vVBgZQSG2Khr6UhhftCwhbQOiSlJQtxPkvFtn8GG0z9wBGWzZCVkQx5HpemND57EuwkJ2GVou11qwXdPeRs30Vx8s3EvB2+MB+805ucNIRbwtid/g7dSwWbZjDRHVnw7yL9tUDppkC0DF2suUsO4lz2PlmfzOVQ0knhoLBuu5DPPtvvbEnNi+ww3RELlf4U0Ujeks1Icgo2ndHQkcbWVIlTYx6T1m1vc/oGMg0Nrlpe8/g6GcsXlonVL56RLjn3pkRg2vVpo0Kf1JzEtmCijepxQuY15MrfNuwx4ZnhMw673Lsh8zZ5kH2GAzQ+CGPEo2imhQJNYOS3MP4UA9KPtDKYUgX3U6RXHtFht/stgG8h0pFex4rhscGdezI1jeRv2UtWtCV1hvE4TecNdsynj7Oha2nYzZ6Urbt6MwWOT+3/QR71517hxUdg5OWQWxZv6OVhsNjZXMsd6gm4PFTISpvzHq4IaiE+T0kFM9J+VBH4d7AutzyiVDJQRX9S6872v2Gc8Mh4prqBS5mmViadrkk/Up+hNM2HmBmursQPXt7ZgCakCTSq5R4bU/bA5coKSGIXud7ejMg+57ffCWQahebT/1CTdsV5/49jfCjJX7wyYpcmu4HfYWP4xle6bV1oBStec30ijgUmH083bQXfPVCpfdu9x8gBhNCub3HU6Ty7hiRDZmxWhJ0VW6W1+6qwcIn9ZMuPd6RvJlO+fe1Zdud9BsRo7Gr1C2hidb0zyKXUaxlS t0+py/8+ 91b/IewkiBP5QoKdJTNukP4lWX8OHJdjL/b25/Pwp2k8x9+nN5pIVx7NG/kBBazOyExm/3teJ55KqGhQeFDE5SIa8xABT4tscHgcDrJCL+rfawx6IhqzGVarz19zeLjALFrlsCJcknhhkluI9QoVeccnvLHiOztB85K0JEgqyGVKoy+Dq1qBeQqLpVg== 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, Jul 25, 2023 at 11:53:26PM -0600, Yu Zhao wrote: > > +void folio_remove_rmap_range(struct folio *folio, struct page *page, > > + int nr, struct vm_area_struct *vma); > > I prefer folio_remove_rmap_range(page, nr, vma). Passing both the > folio and the starting page seems redundant to me. > > Matthew, is there a convention (function names, parameters, etc.) for > operations on a range of pages within a folio? We've been establishing that convention recently, yes. It seems pointless to re-derive the folio from the page when the caller already has the folio. I also like Ryan's point that it reinforces that all pages must be from the same folio. > And regarding the refactor, what I have in mind is that > folio_remove_rmap_range() is the core API and page_remove_rmap() is > just a wrapper around it, i.e., folio_remove_rmap_range(page, 1, vma). > > Let me post a diff later and see if it makes sense to you. I think that can make sense. Because we limit to a single page table, specifying 'nr = 1 << PMD_ORDER' is the same as 'compound = true'. Just make it folio, page, nr, vma. I'd actually prefer it as (vma, folio, page, nr), but that isn't the convention we've had in rmap up until now.