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 C0C12C369C2 for ; Tue, 22 Apr 2025 18:50:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0AD3D6B0008; Tue, 22 Apr 2025 14:50:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 032106B000A; Tue, 22 Apr 2025 14:50:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DF1966B000C; Tue, 22 Apr 2025 14:50:49 -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 BC4E96B0008 for ; Tue, 22 Apr 2025 14:50:49 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id A8ABB1614DA for ; Tue, 22 Apr 2025 18:50:51 +0000 (UTC) X-FDA: 83362571502.02.FED2885 Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com [209.85.167.49]) by imf29.hostedemail.com (Postfix) with ESMTP id 9ABC6120013 for ; Tue, 22 Apr 2025 18:50:49 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=eumJV4VL; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf29.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.167.49 as permitted sender) smtp.mailfrom=ryncsn@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1745347849; a=rsa-sha256; cv=none; b=y9nhMxx7ydpXQ4dLlV5nhuICr2nvZTIDNP2sOrW3OpnL8HHAcGW2qAzEpThqFJSl34gPas oLtE8cc0YM8KUhJDRhIMiv79UPWspM+Oa2pblRQC5Yf+qbMPVFuaOU5NoMEf/37hpx5utl u2Iw2SD2YZkwVEAwLATb4le5USdTz6Y= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=eumJV4VL; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf29.hostedemail.com: domain of ryncsn@gmail.com designates 209.85.167.49 as permitted sender) smtp.mailfrom=ryncsn@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1745347849; 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=Ik4wMhUz7DWmnlFro2ty1aoiaCrY7XiTZ8hSwwJ7ppI=; b=g9aPJDauGtjX667icn+njusdUBjHFbjmWoqa99L2FcHLJ/F6fq9Hi/joAabaSXcW8Cl53m PzC/WUk5vQ4teLhQ8wKxzxtStvjueleQPhjHMv6Vwu47yASjWft/yeKSddUQxJziO7+vPf 0LABR73nTNDQ6FQe05cjY2CUdFgA6n0= Received: by mail-lf1-f49.google.com with SMTP id 2adb3069b0e04-54996d30bfbso5008890e87.2 for ; Tue, 22 Apr 2025 11:50:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1745347848; x=1745952648; 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=Ik4wMhUz7DWmnlFro2ty1aoiaCrY7XiTZ8hSwwJ7ppI=; b=eumJV4VLBHADPFz0dbVvTXNErGuPfTX13intgVWZMz49ENEEH+PJSwQy3Xuj9+JtQ/ ZbHyONKRYzeBXgHA8lgELlttXwr47gZi4GC6zKnczDsNNI/m2voQBfTT7Li49PS1VOwy kzzPri7K0g+eZPwH6NTQqO2AU8S7Vg764KmQ080bNHiEaiTLccZrfxujFA1q5k9FPd/o pvfsBSZgVFUnJlxrhMW0Hvl05VGVkXsXTBXjyonUmHgwZodaZkGasHIh97xVm7x8kWRS pKmIq8C1SLmtHl3uE8g+ZpOPpDW1VcJRTl0p/12j+lrKzyw+QyWgfjjzfSNBw34vodEk DlYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745347848; x=1745952648; 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=Ik4wMhUz7DWmnlFro2ty1aoiaCrY7XiTZ8hSwwJ7ppI=; b=iLjB2e+LF5y2mFa3lvykT+Ql8ClWqxQC3bwBzKGWzSaM4zLmKnItJKTeokFCFbz7iL 9+79bEZlUUep+jDWh89DnvQBiS4IsbQNGhmlOknvnSs4SKwlHSbdlN+EU8ddwVWRKaCL EpS3QPjwbowz9Bh7IZ6kjxLPwbiXTVus+Dzt50VZwjj/RaGPDJSL+5R0uX70IEb29TuV 5IRg2B91XDzOlOpvxzPQmTQBNGIyrgOs5elvGj8oyy5iEBDKVWzhOJV3Xc2JPkXkrT2u DzWBEccaRHH6gHdjS2fi8mFvz7UXJqAgtuISngd+nFL0N2DSonnUOtDQhoNYAW/RVbjS bPAw== X-Forwarded-Encrypted: i=1; AJvYcCWjhxQDhq4OMNHyW/UsnZU4DvvWkEyp73RXtMgg+kiQ+gKIMU3jKwM3RmcMIJa9yVWkBqAZtYm8PQ==@kvack.org X-Gm-Message-State: AOJu0YzFWuD1AKc9SdVIa/W275UhR9HsIAoEaE8BYD15sfhLfHe0BfA+ 4qw/udKDZgtdxwM4sGaOFc5p6mOlR3IwfiTmTrns3Geb9ALQGU524lRpAfMYv8yYpug8oxk8//4 4fQTDAamavBoSoki8MV1G63jS2KY= X-Gm-Gg: ASbGncuO6RPdqnDy10J0/7MNWPdTyeuE5qJXH3DLE0s0nKeJqOqlM1Iu+Gt8L1GM9U1 +w3HPwf8Jj+RJjh3Xne9m+8vz3ctOd6GbesfkoFBbM3Ry7U0BS4ClKH7E80qdbr6bMtzQch29dV w78LYe3W10p+YzToIKxy8BGg== X-Google-Smtp-Source: AGHT+IFECvUxK/U/6K7wE1qIHI7cyjrKwKN10Zq6Tl5Y1zH18ONpTEa9mG5f0LF53kkT9psSYucYWpdLvLEmfUvl9B0= X-Received: by 2002:a05:6512:3c87:b0:549:8924:2212 with SMTP id 2adb3069b0e04-54d6e62c0damr5429654e87.17.1745347847305; Tue, 22 Apr 2025 11:50:47 -0700 (PDT) MIME-Version: 1.0 References: <20250407234223.1059191-1-nphamcs@gmail.com> <20250407234223.1059191-4-nphamcs@gmail.com> <20250408141555.GA816@cmpxchg.org> <6807ab09.670a0220.152ca3.502fSMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: From: Kairui Song Date: Wed, 23 Apr 2025 02:50:29 +0800 X-Gm-Features: ATxdqUGmNlJy_pbW-0fTae4V13peiJz7II-wVjd0eabDB5V7Nz6eDeyVg6cui1w Message-ID: Subject: Re: [RFC PATCH 03/14] mm: swap: add a separate type for physical swap slots To: Nhat Pham Cc: Yosry Ahmed , Johannes Weiner , linux-mm@kvack.org, akpm@linux-foundation.org, hughd@google.com, mhocko@kernel.org, roman.gushchin@linux.dev, shakeel.butt@linux.dev, muchun.song@linux.dev, len.brown@intel.com, chengming.zhou@linux.dev, chrisl@kernel.org, huang.ying.caritas@gmail.com, ryan.roberts@arm.com, viro@zeniv.linux.org.uk, baohua@kernel.org, osalvador@suse.de, lorenzo.stoakes@oracle.com, christophe.leroy@csgroup.eu, pavel@kernel.org, kernel-team@meta.com, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-pm@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 9ABC6120013 X-Stat-Signature: 3fdwthrbga99dk5m7m8oyseukfqydhez X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1745347849-149618 X-HE-Meta: U2FsdGVkX1/GTVvehTnFiJrqi9mqKaVH1L73CVzYtw2Yfu1jNFYqus/PyXfltZBfBjk+YlN8bo/lLgftG1sh0msm8Bko+jF6lR6CfvlEFgXvrtJh2kSSeW70Qjcp/ZNAmkzmHiXvnG2/eHcjRW++IJBbwNukTmrVbXSBoSxgdaBkP2Va1M79jJGkFmoHcf8FayITrRAp/j6i2wiAhPlJRY3TDwbkfHDDkc3XeJNHhE5q+lbqYCFaNOhSyedRHlqOzV9UiSjhShIgv3LxXEg8B2zXlEMmSx3PhY+xjY8kpGBzTiHUfVK7dsOgunXt0nGCdEJmhD6xKWVzQH69BfRlyHlQDIjmy2hN7Jm1jqk4Nq3HOimwkKDDPG21Q8sIfoBcKee6XDt7IgFi1jUXe0nV8twFq5QkYhTlfHMDWSEMF5WPc+cX3ch0XPvtgkuL6PKlnAL2XSqzbr1G1Zb/jd5bNPgr+fVIDPHjlRNWPdgSdFmKotdinkmTifIsCCJi+qQN52qoZg6AMuBM0AB9C4k90cW7g/CYN90T82/8MUMLQqhuJ6z8abHCzkqobsrATXOuUn/6hHJdwlzs8WefRY8Skwv4+LhSlDZQ7rMktD/LqwWa/Jl0iOJH0mTDrbGMQc/G2Hr5cHvvsFv8ybSKoaxeUTPCYjuJrXGFmxXwzGOnraVHorFEY5iBdw2Tpvstc6jaApTeKmdCnmKVtRsuiMywqWQttMFmZ30KQDBJzv1nLAwSyP9KndPn1cB+hVKHdrlyz5n9hWjJO0o+Q8ALCRaoSz+KsHPWk8s3xFzGKTtEpFXfSvu+UmbLFWPNiytI975iR7tOqgol+Vn7H2iyimOsLCCrB2FFviyCxddROD0TOmwR3nOk3SP54OEZh9tbZFIGoCJ13hBhD47ZD6rmIE2jRYsvloK76q1uFbuLZIwHP0UdSM1y/o9sTVgshjsInhjy1A39vPwajmMIPjUmfJT MTz1t8cq zCBG8q+CQD7/CIHx3nQHKijCg4VcnfVV5AaUcKHGyVvlntWXVDj87DQ2oyu1gOqqo2y8LFmq8FdKPn0Gsitjk/QDbzi9sXPR1ueuAhH6BvfNqPkp8c+H+vCPoF6+ztVWsGQsVJsFle1cmXjsYd2pWamD4MmF71YnwWjVFN78ef1Wy+3TZMjmpScR16py+zubjf/lTU4uoJjHnzS5AXfThi6lMkkWGOgvVMjrdgG3CNMuIrARif3G96cD+UK/+4d9DIcCZrsAHifdKFcorduMCNlY1spyXrXHLY9xPtqA85MVhZI3Mp7RZnBITUWwO6+2mOVZWUPdlEsqJ102MKjj7MWmMAj4pOsngpNKp5ouVnv0/rePgFt49kCxv+822V1VpDonjW5OL8G4n4nLDYChj4H9ZSzOM7csP7vra 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, Apr 22, 2025 at 11:51=E2=80=AFPM Nhat Pham wrot= e: > > On Tue, Apr 22, 2025 at 7:43=E2=80=AFAM Yosry Ahmed wrote: > > > > On Tue, Apr 08, 2025 at 10:15:55AM -0400, Johannes Weiner wrote: > > > On Mon, Apr 07, 2025 at 04:42:04PM -0700, Nhat Pham wrote: > > > > In preparation for swap virtualization, add a new type to represent= the > > > > physical swap slots of swapfile. This allows us to separates: > > > > > > > > 1. The logical view of the swap entry (i.e what is stored in page t= able > > > > entries and used to index into the swap cache), represented by t= he > > > > old swp_entry_t type. > > > > > > > > from: > > > > > > > > 2. Its physical backing state (i.e the actual backing slot on the s= wap > > > > device), represented by the new swp_slot_t type. > > > > > > > > The functions that operate at the physical level (i.e on the swp_sl= ot_t > > > > types) are also renamed where appropriate (prefixed with swp_slot_*= for > > > > e.g). We also take this opportunity to re-arrange the header files > > > > (include/linux/swap.h and swapops.h), grouping the swap API into th= e > > > > following categories: > > > > > > > > 1. Virtual swap API (i.e functions on swp_entry_t type). > > > > > > > > 2. Swap cache API (mm/swap_state.c) > > > > > > > > 3. Swap slot cache API (mm/swap_slots.c) > > > > > > > > 4. Physical swap slots and device API (mm/swapfile.c). > > > > > > This all makes sense. > > > > > > However, > > > > > > > @@ -483,50 +503,37 @@ static inline long get_nr_swap_pages(void) > > > > return atomic_long_read(&nr_swap_pages); > > > > } > > > > > > > > -extern void si_swapinfo(struct sysinfo *); > > > > -swp_entry_t folio_alloc_swap(struct folio *folio); > > > > -bool folio_free_swap(struct folio *folio); > > > > -void put_swap_folio(struct folio *folio, swp_entry_t entry); > > > > -extern swp_entry_t get_swap_page_of_type(int); > > > > -extern int get_swap_pages(int n, swp_entry_t swp_entries[], int or= der); > > > > -extern int add_swap_count_continuation(swp_entry_t, gfp_t); > > > > -extern void swap_shmem_alloc(swp_entry_t, int); > > > > -extern int swap_duplicate(swp_entry_t); > > > > -extern int swapcache_prepare(swp_entry_t entry, int nr); > > > > -extern void swap_free_nr(swp_entry_t entry, int nr_pages); > > > > -extern void swapcache_free_entries(swp_entry_t *entries, int n); > > > > -extern void free_swap_and_cache_nr(swp_entry_t entry, int nr); > > > > +void si_swapinfo(struct sysinfo *); > > > > +swp_slot_t swap_slot_alloc_of_type(int); > > > > +int swap_slot_alloc(int n, swp_slot_t swp_slots[], int order); > > > > +void swap_slot_free_nr(swp_slot_t slot, int nr_pages); > > > > +void swap_slot_cache_free_slots(swp_slot_t *slots, int n); > > > > int swap_type_of(dev_t device, sector_t offset); > > > > +sector_t swapdev_block(int, pgoff_t); > > > > int find_first_swap(dev_t *device); > > > > -extern unsigned int count_swap_pages(int, int); > > > > -extern sector_t swapdev_block(int, pgoff_t); > > > > -extern int __swap_count(swp_entry_t entry); > > > > -extern int swap_swapcount(struct swap_info_struct *si, swp_entry_t= entry); > > > > -extern int swp_swapcount(swp_entry_t entry); > > > > -struct swap_info_struct *swp_swap_info(swp_entry_t entry); > > > > +unsigned int count_swap_pages(int, int); > > > > +struct swap_info_struct *swap_slot_swap_info(swp_slot_t slot); > > > > struct backing_dev_info; > > > > -extern int init_swap_address_space(unsigned int type, unsigned lon= g nr_pages); > > > > -extern void exit_swap_address_space(unsigned int type); > > > > -extern struct swap_info_struct *get_swap_device(swp_entry_t entry)= ; > > > > +struct swap_info_struct *swap_slot_tryget_swap_info(swp_slot_t slo= t); > > > > sector_t swap_folio_sector(struct folio *folio); > > > > > > this is difficult to review. > > > > > > Can you please split out: > > > > > > 1. Code moves / cut-and-paste > > > > > > 2. Renames > > > > > > 3. New code > > > > > > into three separate steps > > > > +1, I agree with the fundamental change (and is something that I > > attempted before), but it's really difficult to parse :) > > > > Also, weren't the swap slots scheduled for removal or is my brain makin= g > > stuff up again? > > You mean the swap slot cache? That's the one Kairui wants to remove (I > think he removed a huge chunk of it already). Right, I wanted to remove it to simplify the code and it is already complet= ely gone now, see 0ff67f990bd45726e0d9e91111d998e7a3595b32, it's in 6.14 And the whole HAS_CACHE pinning thing will be gone too after the swap table series if it went smoothly. My bad, the series I promoted is still not posted yet :(, which is not as I planned... encountered several mysterious WARNs testing with the mm-unstable, some are related to swap table and recent unstable changes, so spent quite some time checking other components and revisiting the series for better debugging and sanity checks. Good thing is there seems to be no more blocking issues now.