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 B7380C48BF6 for ; Mon, 26 Feb 2024 04:47:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D86EE6B015A; Sun, 25 Feb 2024 23:47:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D37596B015B; Sun, 25 Feb 2024 23:47:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BD7A36B015C; Sun, 25 Feb 2024 23:47:16 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id AD06B6B015A for ; Sun, 25 Feb 2024 23:47:16 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 059D180694 for ; Mon, 26 Feb 2024 04:47:16 +0000 (UTC) X-FDA: 81832720872.08.AB93ECD Received: from mail-ua1-f41.google.com (mail-ua1-f41.google.com [209.85.222.41]) by imf07.hostedemail.com (Postfix) with ESMTP id 3B9E340008 for ; Mon, 26 Feb 2024 04:47:14 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=ffZ0X1Nb; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf07.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.41 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708922834; 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=2evqKUntkKcx/ouxIcn5GSYuRU6W+/guAPwVvK2rp+k=; b=hM/I3Y4nKd31zNTQfVsEvS3Q/iB0rG5NdVZS04OCokcxqQOVrtHAUs5iBPSQRhPM3uD/Ej EJ1790swosi6hBMYwgkwo9LE7aKSNksxUBSZ1sNxFcilcdDQKCyaHqGPIfmjEohOJEfsUe syHCnrxf/6gOUppEwvJuxmrr+7/9gBE= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=ffZ0X1Nb; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf07.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.41 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708922834; a=rsa-sha256; cv=none; b=bWIK8d1ojfhqA8EVum8jcqcRQzEFxzq7jZL1e6wNeoz5FuYgekErTaxAKurZxg1PqI5XXw 2TTp8qCJ7db3MyTJH3G/dgPG3JHGvkIfXi81peIMbf+3I02AH95QAgTaVj3IY0imivic2G W42CKRmOsdeIWHXBW+sGQGt0ztQaNZc= Received: by mail-ua1-f41.google.com with SMTP id a1e0cc1a2514c-7d5bfdd2366so1420128241.3 for ; Sun, 25 Feb 2024 20:47:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708922833; x=1709527633; darn=kvack.org; 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=2evqKUntkKcx/ouxIcn5GSYuRU6W+/guAPwVvK2rp+k=; b=ffZ0X1Nb8c8tjqwSV9H253iwOH9KlpTiHY5LjssW8nM4sl0EASXOhwSdZaJrTQeK+J 6y8ym23pLt6F+TuXVO89GyPgfQUKKa93KlN0rJt9sCvMRFFvk9XB8KAFiZ5ZqniG+X3z RQLK2nFq2EyDV4gGfugCmN6xAvUtHlRTp0VkR9kV7chswdH7Ko1h2my2Br5VoCSkHsvS Ol1/T6c/s1Y8sMuh+8FCAspmQ0Kx+Q6JGw43ljTb9UC6TGbW4gsyu21r5ZkxbPi+c4hT ndlwxffvtlsle7natuQpn0rMSfRyLoAyeDOIHMmNmmn6gHx6OfrPXnNZpX1LmQeIhUTw qgfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708922833; x=1709527633; 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=2evqKUntkKcx/ouxIcn5GSYuRU6W+/guAPwVvK2rp+k=; b=NJNBzzxnI+46jAgHdq0RGM490FvOTJXOJwrxgRkWnQ7nDDFqcizyxxNNEJxwydelWy U5KzDkHpMLIXXmJqOU1gRFxy+dEjR101xIddO7t8ybfPihxiu19yxMwRXC3JQMDgsZrc pvVeTVQw5DorHcGDqkrnSBJ4n+pUMabzZ9pgY0NcH8yXN9oZwkHgxgkW+Uvj0AM1pime /sMktJVMIqox96VCOYubhRTkvfj7eDoPbSFxoj2tFF4wtGrVVa+x1k85veKVU47O3nns uevOQPx/46/JvE3CkTL/3nmWmaIue3V64AuUCvSQhJ19K6wYGoHHiqmHh8jRYSKm3Kgv sMYQ== X-Forwarded-Encrypted: i=1; AJvYcCXMhtwBd+u23rw5NHaDPBeaQ7F6dOM54F1/M13pu3iZ72U0Z8PzfBbCayxGtjXTOMNwgJ+zpy2SvHdWgP8xj8C9ZmI= X-Gm-Message-State: AOJu0Yycq3lwij1XfRwL89gRJ0TdF/yTR4eQTyrVDF/vFN5zGjEv48+t uNkWjkSyheObE0ioW0eVfrvyAvM3YylFhrai9CG3p/t2rZpG40fsI3eHKJDM47WW79MfEALn6qd ZkCvFU8ppVu3YTKFBs0Fn/Rm9/po= X-Google-Smtp-Source: AGHT+IHBXtSc0pPDmFFVyN84Q/468/d4r71tO8SRKVOSIw1NeJ246xlCPqVxqgcMScvdWgPsfh9m/Js7eusVj1RMiOg= X-Received: by 2002:a1f:c402:0:b0:4cd:b55a:bb0d with SMTP id u2-20020a1fc402000000b004cdb55abb0dmr2466062vkf.2.1708922833135; Sun, 25 Feb 2024 20:47:13 -0800 (PST) MIME-Version: 1.0 References: <20231025144546.577640-1-ryan.roberts@arm.com> <20240118111036.72641-1-21cnbao@gmail.com> <20240118111036.72641-3-21cnbao@gmail.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Mon, 26 Feb 2024 17:47:01 +1300 Message-ID: Subject: Re: [PATCH RFC 2/6] mm: swap: introduce swap_nr_free() for batched swap_free() To: Chris Li Cc: ryan.roberts@arm.com, akpm@linux-foundation.org, david@redhat.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, mhocko@suse.com, shy828301@gmail.com, wangkefeng.wang@huawei.com, willy@infradead.org, xiang@kernel.org, ying.huang@intel.com, yuzhao@google.com, surenb@google.com, steven.price@arm.com, Chuanhua Han , Barry Song Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: tgtihybn9j4mj9hp65xi4f5584ra1pjo X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 3B9E340008 X-HE-Tag: 1708922834-505917 X-HE-Meta: U2FsdGVkX18JYPPqpWvz8Tmo4k/EUO2MnFbFL2UKNHX3D6AMCuLPgLa/TXzJI2eycUDYoYEQ/NndXah3IYSxegHb7x5KYzI1HQKF8ub/pV0M/q0yaaZC8jRi19QRwaXWLUPe/LD/aWgBi+b2+rNpPnbUZwr5ve6Ss+t3PF5u/BoLEiPRZS0JhZOBz1q+Di/DUEwIPLXlwKRY9fXuY/hfMMBZBn+dwqze7esdaUHc646/C9B8xT2VrA7WLGDX9X1AKYAcoDgqDlmYcNmV+pyv76LJGlxG+sG0qGtKKtvT57iMG/3MKX/723rDrx8ji+odNHejkqOb0erDpOwbc2ctHJhfIy07Jc8Nna3CLJe050Bnuv6GidKRPMBOYoBqLa2rjGMy7cIrrWlZSzuFV6Zohp04ONXRfabwl8qYUVkR1Qfc6m/14yXS0e0qwBq9OvqGSNDdWSv/J3+A69f5BhUcsTWQncwwLqf/dtJuQXh4N1dcRVj2v8i0Yfyv9ctYc6Q4tugm+MXGT6gbO57LtQdo5tjSBFGX7tHTC0vFCId+DHiif+v7qE49badaTC89B/rYF1LMoHICMzAdBi/ovr71uuwoTyk+n/vMyt1op83c8+ahIJglbpGolgINetC8TwQOqwkqd0sEWeTZ/1W+92nh+PN88LWao0CRghPIjwCKfT9ChyIvvOovtCr+x0j4UiuNX5LvUGHyqyXI4koVUdcp5IfnSKAwt1gQJvvlTdDoLqN+cbnVIrC0z9wQ9ZqA3iFwi7ufCkgzFAvPy0/38oa94sKZ7ywtO0A4fr/NhHijNKLVBmzVHb0rZTvP87xtaf0JUZNAoRwmLsPHAmViC8855d5P9XkwLDPuUpA4ZBuV2Os86pshqn3t0JTrMDxcI5Xq3xdWPRa6nuYOfrOkSEnJ7Q2P0hu8cBUSGY5m7qcB08b0Rm68EhZplmkWrUubmcSHT721QQn8eyjmepWmqL7 C9zHQDb0 AAodaZhx6/8+pSyXiKRAuElBDd1bXgfhLNdw58SzHaa04blrHTqJJwYIppYV4//XBFR3lt+cFCgPKFc6OozGXJVuz2MQNwHIV8IpxHhhnSUgHhhqAIyljaELNP4uC4JB/xXCOBM2k/XJ8yM7JqgtgwwE+s+KRUVNId8rvlTKzqnJ+HbGo04jEUmdGHhlRZBfla7M2PXjZS63hUb80uB8nXRTkwXfVa004gf/JVNz5PHW00xVbTvOoHN04bNHa33uzSwJtUMhFzZ47aCfcbzMu2dmKu7dr6eT3bjzVAdBiZo0Pd/eekc9hK23UOsoid/dQoiQk9qkFWAHIrvUrSXVW5+0V647sM2Y5J8y5z53fpikN9XYS7Z7MXHgGTWKhmvao5NUbagK4fIUJdyAfGCkbTAKcNhM1h7pf1u0XY/OVa2gLRcYZ3O8xURFvxF16ss18dsr3gZQ8seCU/8sKHTwHSQAP9EVhQBl1s6XdLsSZR4JUoMPv0RtC/SgPgrFwR9XJd8oBYsB7Hiq9m5p8/Fy4C0Mno4jueY4ZstaJ 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: Hi Chris, Thanks! On Sat, Jan 27, 2024 at 12:17=E2=80=AFPM Chris Li wrote= : > > On Thu, Jan 18, 2024 at 3:11=E2=80=AFAM Barry Song <21cnbao@gmail.com> wr= ote: > > > > From: Chuanhua Han > > > > While swapping in a large folio, we need to free swaps related to the w= hole > > folio. To avoid frequently acquiring and releasing swap locks, it is be= tter > > to introduce an API for batched free. > > > > Signed-off-by: Chuanhua Han > > Co-developed-by: Barry Song > > Signed-off-by: Barry Song > > --- > > include/linux/swap.h | 6 ++++++ > > mm/swapfile.c | 29 +++++++++++++++++++++++++++++ > > 2 files changed, 35 insertions(+) > > > > diff --git a/include/linux/swap.h b/include/linux/swap.h > > index 4db00ddad261..31a4ee2dcd1c 100644 > > --- a/include/linux/swap.h > > +++ b/include/linux/swap.h > > @@ -478,6 +478,7 @@ extern void swap_shmem_alloc(swp_entry_t); > > extern int swap_duplicate(swp_entry_t); > > extern int swapcache_prepare(swp_entry_t); > > extern void swap_free(swp_entry_t); > > +extern void swap_nr_free(swp_entry_t entry, int nr_pages); > > extern void swapcache_free_entries(swp_entry_t *entries, int n); > > extern int free_swap_and_cache(swp_entry_t); > > int swap_type_of(dev_t device, sector_t offset); > > @@ -553,6 +554,11 @@ static inline void swap_free(swp_entry_t swp) > > { > > } > > > > +void swap_nr_free(swp_entry_t entry, int nr_pages) > > +{ > > + > > +} > > + > > static inline void put_swap_folio(struct folio *folio, swp_entry_t swp= ) > > { > > } > > diff --git a/mm/swapfile.c b/mm/swapfile.c > > index 556ff7347d5f..6321bda96b77 100644 > > --- a/mm/swapfile.c > > +++ b/mm/swapfile.c > > @@ -1335,6 +1335,35 @@ void swap_free(swp_entry_t entry) > > __swap_entry_free(p, entry); > > } > > > > +void swap_nr_free(swp_entry_t entry, int nr_pages) > > +{ > > + int i; > > + struct swap_cluster_info *ci; > > + struct swap_info_struct *p; > > + unsigned type =3D swp_type(entry); > > + unsigned long offset =3D swp_offset(entry); > > + DECLARE_BITMAP(usage, SWAPFILE_CLUSTER) =3D { 0 }; > > + > > + VM_BUG_ON(offset % SWAPFILE_CLUSTER + nr_pages > SWAPFILE_CLUST= ER); > > BUG_ON here seems a bit too developer originated. Maybe warn once and > roll back to free one by one? The function is used only for the case we are quite sure we are freeing some contiguous swap entries within a cluster. if it is not the case, we will need an array of entries[]. will people be more comfortable to have a WARN_ON instead? but the problem is if that really happens, it is a bug, WARN isn't enough. > > How big is your typical SWAPFILE_CUSTER and nr_pages typically in arm? My case is SWAPFILE_CLUSTER =3D HPAGE_PMD_NR =3D 2MB/4KB =3D 512. > > I ask this question because nr_ppages > 64, that is a totally > different game, we can completely bypass the swap cache slots. > I agree we have a chance to bypass slot cache if nr_pages is bigger than SWAP_SLOTS_CACHE_SIZE. on the other hand, even when nr_pages < 64, we still have a good chance to optimize free_swap_slot() by batching as there are many spin_lock and sort() for each single entry. > > + > > + if (nr_pages =3D=3D 1) { > > + swap_free(entry); > > + return; > > + } > > + > > + p =3D _swap_info_get(entry); > > + > > + ci =3D lock_cluster(p, offset); > > + for (i =3D 0; i < nr_pages; i++) { > > + if (__swap_entry_free_locked(p, offset + i, 1)) > > + __bitmap_set(usage, i, 1); > > + } > > + unlock_cluster(ci); > > + > > + for_each_clear_bit(i, usage, nr_pages) > > + free_swap_slot(swp_entry(type, offset + i)); > > Notice that free_swap_slot() internal has per CPU cache batching as > well. Every free_swap_slot will get some per_cpu swap slot cache and > cache->lock. There is double batching here. > If the typical batch size here is bigger than 64 entries, we can go > directly to batching swap_entry_free and avoid the free_swap_slot() > batching altogether. Unlike free_swap_slot_entries(), here swap slots > are all from one swap device, there is no need to sort and group the > swap slot by swap devices. I agree. you are completely right! However, to make the patchset smaller at the beginning, I prefer these optimizations to be deferred as a separate patchset after this one. > > Chris > > > Chris > > > +} > > + > > /* > > * Called after dropping swapcache to decrease refcnt to swap entries. > > */ > > -- > > 2.34.1 Thanks Barry