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 B62B5C0015E for ; Wed, 26 Jul 2023 05:54:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4F5488D0001; Wed, 26 Jul 2023 01:54:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4A34F6B0074; Wed, 26 Jul 2023 01:54:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 36AC98D0001; Wed, 26 Jul 2023 01:54:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 280816B0071 for ; Wed, 26 Jul 2023 01:54:05 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id E6C9712015E for ; Wed, 26 Jul 2023 05:54:04 +0000 (UTC) X-FDA: 81052697208.25.8FA7DA1 Received: from mail-qt1-f181.google.com (mail-qt1-f181.google.com [209.85.160.181]) by imf07.hostedemail.com (Postfix) with ESMTP id 31BBC4000F for ; Wed, 26 Jul 2023 05:54:03 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=kNdc+Tjf; spf=pass (imf07.hostedemail.com: domain of yuzhao@google.com designates 209.85.160.181 as permitted sender) smtp.mailfrom=yuzhao@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1690350843; a=rsa-sha256; cv=none; b=hszhamwfDXF3N7VA1f9hyM2mzJoMbYSZkyOmJtlm1p+Lsr51d1qIYyEsohiqMtAoZ/RyZs aXHJLHNJtqRzPrN8vn0rlpXudR2SqLi0mvIflQ7Fp/DjicmCgSs4/Pq08YvIlAzTqpZXLc xHthdPEHKCUazicLi1XxmWxVQS1upsY= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=kNdc+Tjf; spf=pass (imf07.hostedemail.com: domain of yuzhao@google.com designates 209.85.160.181 as permitted sender) smtp.mailfrom=yuzhao@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1690350843; 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=8jC3sNXdTqmH+eXOZrdrV9yhRQ5WjXD1etqf4l0CXD8=; b=hlwL8Apx0gj8mAIwkISbDSwnqQbB5obvs2pAdnkI6MFxRRHZtFBRq7uvGWqRNMLl35T/Wl b36F4XrbbzLT1SeTLg4Eci3WGer6y6YNejjEKw0dg19oG3zu2WYiIcqFlzfCxBH9TNEPY4 ey7WVzTiGVLhrgFFZo/BaHpcGD909XY= Received: by mail-qt1-f181.google.com with SMTP id d75a77b69052e-40631c5b9e9so159531cf.1 for ; Tue, 25 Jul 2023 22:54:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1690350842; x=1690955642; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=8jC3sNXdTqmH+eXOZrdrV9yhRQ5WjXD1etqf4l0CXD8=; b=kNdc+TjfV0H/TBWzGhIgAI93ibQ6iIfvmm3jyasTUe4JrmcpVKMNJUb92GH1Je1RHG JtWPMEbH0nI6kj1QHNethWv0RMC15Qo2rqaQpdFq8zTVXjCH/Km0JAfZgPt2mPXiAm88 LMnF/RDqrOZcA/XvEcXUWEqwJOzKnrSM16dMoBMsknlptCkYhOAER5cMgfaYoEh4AuqX ob0DMqdnmJ9qTExQ30MAHFHVKimn1NsSO84avLhNa4SzB9FG2bjTxnqhbO5dc6Pnaz3I 8n9XaFP/B3pERaAQJm8Csq45Vdyfz/5aJtpKpBXgVRyAE3RT0DOhmS1FsPZ5/7akkm/c R1Bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690350842; x=1690955642; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=8jC3sNXdTqmH+eXOZrdrV9yhRQ5WjXD1etqf4l0CXD8=; b=SFiHwmyINelIexpHbXmRVT/ctA6TOOcClITyeByoQE+/9bLJdTcdxzmeUXwH6OpICi h5RjcA0GS4gNrYlAPzSbcvEFVolHQUgoWVya517PkC3OphSq99plwvcu8zbIYazSaHmH XXTe7z4dMOVtm/0ByBhfh7YSkhtuJ6AhagAGLDM8KfOTN7WycGSlUbtgTtfOw+fldau7 EV3qqEpw5CTZAKLZoStPeCMvbYAMa7+aJkLYM3tpsdlwfbXT9txYIliaqbguSe5oHLnL VnK8WeQZsJBdoTKmrkK8fMGshxHbbsCZCnwc8NDSNd+JNvmOdaiZ32RO98B8SDbUe09R YoPw== X-Gm-Message-State: ABy/qLYwOKZG785nDaqIa+W3V15ajbJBHILX0LHYRUOqPkLF6O+ZKTm6 E3i0/FPs7hQfMsBkbH+o7Na/WJVUG2WTNnHBJ4WkeVDSRquiEGgpV70= X-Google-Smtp-Source: APBJJlHZ+/qIFGCOIW2GxP98uJ1C/0nh99PCGNYz0dkn1fWzZTe8CIpbq/96sCEfO9aknQ72JuQ//pPUEx3R/kB+ldc= X-Received: by 2002:a05:622a:14c6:b0:3f8:5b2:aef0 with SMTP id u6-20020a05622a14c600b003f805b2aef0mr440236qtx.24.1690350842297; Tue, 25 Jul 2023 22:54:02 -0700 (PDT) MIME-Version: 1.0 References: <20230720112955.643283-1-ryan.roberts@arm.com> <20230720112955.643283-3-ryan.roberts@arm.com> In-Reply-To: <20230720112955.643283-3-ryan.roberts@arm.com> From: Yu Zhao Date: Tue, 25 Jul 2023 23:53:26 -0600 Message-ID: Subject: Re: [PATCH v3 2/3] mm: Implement folio_remove_rmap_range() To: Ryan Roberts , Matthew Wilcox Cc: Andrew Morton , Yin Fengwei , David Hildenbrand , Yang Shi , "Huang, Ying" , Zi Yan , linux-kernel@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 31BBC4000F X-Stat-Signature: ntsy5jpfcie1h58uc5a17r7h5ur1uimc X-Rspam-User: X-HE-Tag: 1690350842-2010 X-HE-Meta: U2FsdGVkX1+Ni23zcZTUHHoGZ+ftoJAVX3rFQiRMmScMk2dia1y3KFd0wUWdA1fgzqZYk+aRmE5qJB3r2eOl7t36wq3q5EazBb3M8N6s/Oi8cSxfk5ybuZeD3+mq2oIRsKJsr6U5mTv/Uw7EOAui00WEnpyfSX5ehBMfRk84b5gNQ0omsh5QV1zca4bMLNbVEXm/HvTCZRK4b8HKIGC3aK6iOcbsI/4xd6tHaGildDnCmoXprfj8jM6tpWbPexA+mrbydnmcJaJRb7PSVbyZQgHVOtaYlG52rrTXsRTDaUbQJ+Yd8XSLHs4Iy0X46p09zgU3CqAEDz8Ic9+IUJ5RVqsewGJZV4WtKWhaQetOrbiaBD0cANssscxwsiq0E/PLIO7mj5KN73+nRyzbjt9UUnHlrkDHR0+7ncxKvE8Gsy7zN5DvLbzX5OD75NXDipk5XQHaIlMHYiuzOllDFWK65Vupu+BliifocHBwPBjQksvqD4XpgyWkKFkVq8f9U2XGBLvcvvtNFAUk1zQ8bJL9RLGsntKqS7v6VWmmGF6sqI4Uvy3HKN17HPymoZIZH5GgADl+I3p1t5bvbW3zkilu4pIZU0HS2EX10VQW5aR3EndKjJFD2URB4QgtDMM/8PQtq9ptXMyg+3P4FYJ84YYjwtbDL+cCseLcWiMhu+Zk8ZQGRZ/Ale2oy+8ed7I0O8QGtbaH/BLRql32kjVfB+f2TJmalnVrE8DDBcM878lfUsE2DhW1SnLoOrAGaMYz1F0fwSz0w7LYO64nLLzBClAzITPkgVddRdjgBcNWNXwnOHgSAaTyf4PX8KbxjTUv12H8pGPWV7xkMwt0Q4YeBB5oX4G4tvvsf3xguCrXr3cGSXbLsR935ViYIqAwoZ328ja4U0c94vm7s4UuVODRzk5tZsbbrdYZnfZt9bKT8EaKMAAWauKSYfW5BMEqbQw3roEl6HlXT3DQUpGgMpQHhnO x+CljS/u 6PD/JgcuseXZ4MsJ0PdW+bTi0PU3NDAxg13rinsQgE7KaOM5j9Wxb48X8PLiwPcX0IetoprX3FHYqVelDmZuBJPM0Bk1XHDbdxiGi5b3RsFS1VaT14mz1Gnb862ityWPkGDWRsCuhqRuILKyDgkxllm91DrTz5LoZu64k3A3u7sNSYWIUt346C834zPDNBXmjIg8VT2ibz33WwLwzlKOR6o/dpulIK6AkVFRpqKU7etMsxfAfMTZjHM/VXa77uXD6woU1aE1euYO0+/1eAs8HIf83b81n02EBSRGQxBArOfCRFHXKE+8UKEC63DVPNDlHnMkVs1bMLxTnVJq9LrwPLkoGLQ== 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 Thu, Jul 20, 2023 at 5:30=E2=80=AFAM Ryan Roberts = wrote: > > Like page_remove_rmap() but batch-removes the rmap for a range of pages > belonging to a folio. This can provide a small speedup due to less > manipuation of the various counters. But more crucially, if removing the > rmap for all pages of a folio in a batch, there is no need to > (spuriously) add it to the deferred split list, which saves significant > cost when there is contention for the split queue lock. > > All contained pages are accounted using the order-0 folio (or base page) > scheme. > > page_remove_rmap() is refactored so that it forwards to > folio_remove_rmap_range() for !compound cases, and both functions now > share a common epilogue function. The intention here is to avoid > duplication of code. > > Signed-off-by: Ryan Roberts > --- > include/linux/rmap.h | 2 + > mm/rmap.c | 125 ++++++++++++++++++++++++++++++++----------- > 2 files changed, 97 insertions(+), 30 deletions(-) > > diff --git a/include/linux/rmap.h b/include/linux/rmap.h > index b87d01660412..f578975c12c0 100644 > --- a/include/linux/rmap.h > +++ b/include/linux/rmap.h > @@ -200,6 +200,8 @@ void page_add_file_rmap(struct page *, struct vm_area= _struct *, > bool compound); > void page_remove_rmap(struct page *, struct vm_area_struct *, > bool compound); > +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? 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.