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 312A2C04FF9 for ; Mon, 15 Apr 2024 09:01:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BEA426B00A2; Mon, 15 Apr 2024 05:01:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B98E26B00A3; Mon, 15 Apr 2024 05:01:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A61266B00A4; Mon, 15 Apr 2024 05:01:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 88C726B00A2 for ; Mon, 15 Apr 2024 05:01:31 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 467931A0497 for ; Mon, 15 Apr 2024 09:01:31 +0000 (UTC) X-FDA: 82011172782.05.0E6F35E Received: from mail-vk1-f178.google.com (mail-vk1-f178.google.com [209.85.221.178]) by imf01.hostedemail.com (Postfix) with ESMTP id 6CBBE40002 for ; Mon, 15 Apr 2024 09:01:29 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=gVvDtADO; spf=pass (imf01.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.178 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1713171689; 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=AftYN0D42u8gxKw8ofiGJ1Yy9e6/C1aoGJ66ySgQIEk=; b=ZK/wEaj8fMNpiKfw4hYgWVB/Mx9NC5bF3AqWOjXv4Yn2cZ3UeAvkupT5sht9UQussCEz12 xkyQAsVUQAPfv069pQ1Aa0xJO1yrUURWJYAYZSsMcoUHJoprOafZVI28uT2X+nVBdP3Rtz hex2v9PaSEzc0KHHsJi6ajAql8fpuAQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1713171689; a=rsa-sha256; cv=none; b=gRVLcVPKg1vdHpxJHldODCKhfDoczztgDV+dzSZKjRnzU2joM5Hmsb0/gD6cpD6QkY+EBw F1K1T5F/vcD2qX0hKHjfBghFGjMTbD9xuZADg74XCN5L7feG3NO70sGHYN8xhYwP9nHRTD OKBfKEO1pTeji3UVWf9rzZpfdUx+Oxg= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=gVvDtADO; spf=pass (imf01.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.178 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-vk1-f178.google.com with SMTP id 71dfb90a1353d-4daa91c0344so1437596e0c.3 for ; Mon, 15 Apr 2024 02:01:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713171688; x=1713776488; 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=AftYN0D42u8gxKw8ofiGJ1Yy9e6/C1aoGJ66ySgQIEk=; b=gVvDtADOwhbFwKQf9OaKct5/zl374z9VWd81zeTTkcS3daEdK523Sn+nSq9elpLqDv BlBXMpuve2deUHBX8a8OvmHBrKae5ExG3/HhRgETjCqE/fzzo0VV8t2z4Djc17zpZQ8z /UddXj8o9/E5AgvdlsPsQISuqIJZW/Vq/ROkDZhrd0XT6oX9hr/ztQSggE9uPCKIHF7G PBTvwDL/USt6UtJ/Hq5laqfkXNqyCQDoWpAKkJq7wDcR187xE9YZ7vT71tq526ejiASV zPehaxpQz94LKXjKRF8lumcKyPsZkcoszuDiVE42/6aI2idyQw824ki+elcOr/ON3/kh d5lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713171688; x=1713776488; 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=AftYN0D42u8gxKw8ofiGJ1Yy9e6/C1aoGJ66ySgQIEk=; b=pAyDbKM7WxhA64BccFhjlYpG4uSmGPX6uiMsQbfRx0hNuwpqImyEqMUDfQILlrb5p3 KaEXEBiAJqBW089Qi7kQIpGTiHjE9xkRdeq9ss9Zv5Vi3DOKbIHKkyjcsj5Kyj30mZwJ WP+OC9A1PSLhd0sJfDK0SKlR+X3i5oWoID32TCTb8ywUM9aP7Z21zVFxLmjjPG4pj8f1 Se1XAUOMNZl78dY0Mfuoiqi1Dyx6YQTAwZaYznKqaeoDx3qAT6uEzztj6F9OIHtZd3hO Lc87zUs+3RQ4GkL6oigyy1qmKGqNE9aXuTUXopXvrmwp9TyqTk5R18AzeVWdVh9nAvJ1 g0Xw== X-Forwarded-Encrypted: i=1; AJvYcCU+P/pJeM6i3AwrHoOlSb1vHxiFSAqqdFIYev5wQqgWW3S8RsCnVABHDqj2GuAMJTnw9Tt+lQwu4vhYyivInl5wU6w= X-Gm-Message-State: AOJu0YyTGeEIHQkac+etHSS7dzTpoMN67Rkrq4AfIs9AB4wMT158xxsQ PW/eR5kuQkfKaCmKtr6IqG0VbbsgwmXMQ+CwH5xh9rK13srJ843u6GKoZbc8980HB4snIYB4LqC fbV1Luj860JB7OIoDqlXGXcOnmYk= X-Google-Smtp-Source: AGHT+IH618bXsxW4Bii6DlKFO8Z7fwdW5rXKj2ChWf9kgtiaII2cgrUtgzxst9HurH4HQWPEYsFh4TE3AhJT+egY+UM= X-Received: by 2002:a05:6122:2023:b0:4d3:3b1b:aa92 with SMTP id l35-20020a056122202300b004d33b1baa92mr6756178vkd.11.1713171688433; Mon, 15 Apr 2024 02:01:28 -0700 (PDT) MIME-Version: 1.0 References: <20240409082631.187483-1-21cnbao@gmail.com> <20240409082631.187483-2-21cnbao@gmail.com> <87y19f2lq3.fsf@yhuang6-desk2.ccr.corp.intel.com> <87jzkz2g3t.fsf@yhuang6-desk2.ccr.corp.intel.com> <87bk6b2elo.fsf@yhuang6-desk2.ccr.corp.intel.com> In-Reply-To: <87bk6b2elo.fsf@yhuang6-desk2.ccr.corp.intel.com> From: Barry Song <21cnbao@gmail.com> Date: Mon, 15 Apr 2024 21:01:16 +1200 Message-ID: Subject: Re: [PATCH v2 1/5] mm: swap: introduce swap_free_nr() for batched swap_free() To: "Huang, Ying" Cc: akpm@linux-foundation.org, linux-mm@kvack.org, baolin.wang@linux.alibaba.com, chrisl@kernel.org, david@redhat.com, hanchuanhua@oppo.com, hannes@cmpxchg.org, hughd@google.com, kasong@tencent.com, ryan.roberts@arm.com, surenb@google.com, v-songbaohua@oppo.com, willy@infradead.org, xiang@kernel.org, yosryahmed@google.com, yuzhao@google.com, ziy@nvidia.com, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: zjfjc7ac58h9jpu8h4z43rrb7i5e8si4 X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 6CBBE40002 X-Rspam-User: X-HE-Tag: 1713171689-956572 X-HE-Meta: U2FsdGVkX19drh1Nne3m9aBxivVY5sqdtoZoPlCcFbXB65ZUBygg6YHE5MK6WKC5qVt4vQAlP+UlvvDJKWbDxjvqdAprZFgXIxwexHV5upf0O6ySbGM2k3JtAHV4OFbEJVVB9pxIvHxw+66q9XP5PibIUoempAxo0eMy4SlY4YNq/SCD0e8/Dn84LaX31Xoq4g5zGGGbg97Gbl9TEkKHEZ/+VerIq48VPr7glcdfqwHbu4htIVv9nnTqYPSw8BGIw69eC0O082gWIKroz801OKaXexMntrfTm25vancpwcgL0R5eDp9lnqqytQBIp3sDowxa9lifdlxb4YiAZjGiHF6FsAcSIw00aJYT2IHfWuTAFgJ2/Wtf/a+DI5L5lI7bg8BlvnpRhkllU+alN+1w7u/boQb+kBC2pldIr2LLgYkR1yZq8hOj7sX/GSKEak/AR8ExTx2ylZb7eT57E1N8lbBTjcNKEqaCO5SvWnr9nVZlXxzyqPrWB/AfP8iISfGTD7ARJmw/XeaWX/xEKHKEpuDP/46xKFXIar/2NmeJ2vQigXlJMUOviaPiiXx7Da6StMDAm8XG+GWIJWpDrHboHlyz79kemrS7izOdyxAvBLFp6oH4iNdyUoAUS+bnY6DetdgMEfNDnUqkttKybQq2ga1qa2ZHO4DhtXYPcoqHPz7l2fO1cntAjboGWIx/majqIch9EJwoEyYm9XsnCXK9Qjwhjneln2nKWMJZ3GLOdeENYmwpnQxoLdV9n6tuv7ragim1JbW10XsRd61FktCSQwxG1/sfoWkZCJYvjnadqBm4NJyy9bX/qnEbUHxkbvLTy9Pu77sNC2AmZO/tu0bRxggEr9XeCVCKS7qe057bPt74w2ZoU4EyS3OwwUQDdKi22HmcemHVd950bRSc8gj0396+9yJONhvGKmRGLmIyPvGFBKwQa35qqHBYb8Fk7fFpG5qBtWcJkAslf4horZc sS28vOxj wfP7WDckW4gGLkJsLVAI97+C/kq7jxzHZjnwmrtot3OsjYKZLpsJV5/E+7gAesJUKpM/h/JoHpUMSqRcYYRvjDsO2AKo+pr1J1kyqJ5FAB7C7Lyi4Xcld7XfxzvR69wB7+ObA+9pvwa1646omlrMCfL7bzuz90DoGGSO7dxXX5Z3THrpI+su8cFuXm9UAzW88c1Y8mVaP8cdeIViyjawQK6LeZvyHqN2YUSUNeGR4QdMSN6MZu1wRnsB8YRKrNScNOlUjrKksk8mf0z6fh49I38gWU+dEF8PqHmH0dpK57e9/VRSFhzZgOVSRoENCxf4JnTSmQIK3jwEb/1n7wmPMm6dZKRkHolc7wgyATTsGC2Oy1c8hxvC455vMpkf2e89wD/NODauOZ4lqgzE2XKr8shpMoRi4FN9embPSS95gc8mPKjpn68N31vmpeUUbSEcp6WsZJBRbBkyjaixClRjMnXqQOnLd677tOcka0pOpWil4dNo27AenykYp/n9KXTB5t9SUQHN8svmIdrbteloaoWNnjg== 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 Mon, Apr 15, 2024 at 8:53=E2=80=AFPM Huang, Ying = wrote: > > Barry Song <21cnbao@gmail.com> writes: > > > On Mon, Apr 15, 2024 at 8:21=E2=80=AFPM Huang, Ying wrote: > >> > >> Barry Song <21cnbao@gmail.com> writes: > >> > >> > On Mon, Apr 15, 2024 at 6:19=E2=80=AFPM Huang, Ying wrote: > >> >> > >> >> Barry Song <21cnbao@gmail.com> writes: > >> >> > >> >> > From: Chuanhua Han > >> >> > > >> >> > While swapping in a large folio, we need to free swaps related to= the whole > >> >> > folio. To avoid frequently acquiring and releasing swap locks, it= is better > >> >> > 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 | 5 +++++ > >> >> > mm/swapfile.c | 51 ++++++++++++++++++++++++++++++++++++++= ++++++ > >> >> > 2 files changed, 56 insertions(+) > >> >> > > >> >> > diff --git a/include/linux/swap.h b/include/linux/swap.h > >> >> > index 11c53692f65f..b7a107e983b8 100644 > >> >> > --- a/include/linux/swap.h > >> >> > +++ b/include/linux/swap.h > >> >> > @@ -483,6 +483,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_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); > >> >> > int swap_type_of(dev_t device, sector_t offset); > >> >> > @@ -564,6 +565,10 @@ static inline void swap_free(swp_entry_t swp= ) > >> >> > { > >> >> > } > >> >> > > >> >> > +void swap_free_nr(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 28642c188c93..f4c65aeb088d 100644 > >> >> > --- a/mm/swapfile.c > >> >> > +++ b/mm/swapfile.c > >> >> > @@ -1356,6 +1356,57 @@ void swap_free(swp_entry_t entry) > >> >> > __swap_entry_free(p, entry); > >> >> > } > >> >> > > >> >> > +/* > >> >> > + * Free up the maximum number of swap entries at once to limit t= he > >> >> > + * maximum kernel stack usage. > >> >> > + */ > >> >> > +#define SWAP_BATCH_NR (SWAPFILE_CLUSTER > 512 ? 512 : SWAPFILE_C= LUSTER) > >> >> > + > >> >> > +/* > >> >> > + * Called after swapping in a large folio, > >> >> > >> >> IMHO, it's not good to document the caller in the function definiti= on. > >> >> Because this will discourage function reusing. > >> > > >> > ok. right now there is only one user that is why it is added. but i = agree > >> > we can actually remove this. > >> > > >> >> > >> >> > batched free swap entries > >> >> > + * for this large folio, entry should be for the first subpage a= nd > >> >> > + * its offset is aligned with nr_pages > >> >> > >> >> Why do we need this? > >> > > >> > This is a fundamental requirement for the existing kernel, folio's > >> > swap offset is naturally aligned from the first moment add_to_swap > >> > to add swapcache's xa. so this comment is describing the existing > >> > fact. In the future, if we want to support swap-out folio to discont= iguous > >> > and not-aligned offsets, we can't pass entry as the parameter, we sh= ould > >> > instead pass ptep or another different data struct which can connect > >> > multiple discontiguous swap offsets. > >> > > >> > I feel like we only need "for this large folio, entry should be for > >> > the first subpage" and drop "and its offset is aligned with nr_pages= ", > >> > the latter is not important to this context at all. > >> > >> IIUC, all these are requirements of the only caller now, not the > >> function itself. If only part of the all swap entries of a mTHP are > >> called with swap_free_nr(), can swap_free_nr() still do its work? If > >> so, why not make swap_free_nr() as general as possible? > > > > right , i believe we can make swap_free_nr() as general as possible. > > > >> > >> >> > >> >> > + */ > >> >> > +void swap_free_nr(swp_entry_t entry, int nr_pages) > >> >> > +{ > >> >> > + int i, j; > >> >> > + struct swap_cluster_info *ci; > >> >> > + struct swap_info_struct *p; > >> >> > + unsigned int type =3D swp_type(entry); > >> >> > + unsigned long offset =3D swp_offset(entry); > >> >> > + int batch_nr, remain_nr; > >> >> > + DECLARE_BITMAP(usage, SWAP_BATCH_NR) =3D { 0 }; > >> >> > + > >> >> > + /* all swap entries are within a cluster for mTHP */ > >> >> > + VM_BUG_ON(offset % SWAPFILE_CLUSTER + nr_pages > SWAPFILE_C= LUSTER); > >> >> > + > >> >> > + if (nr_pages =3D=3D 1) { > >> >> > + swap_free(entry); > >> >> > + return; > >> >> > + } > >> >> > >> >> Is it possible to unify swap_free() and swap_free_nr() into one fun= ction > >> >> with acceptable performance? IIUC, the general rule in mTHP effort= is > >> >> to avoid duplicate functions between mTHP and normal small folio. > >> >> Right? > >> > > >> > I don't see why. > >> > >> Because duplicated implementation are hard to maintain in the long ter= m. > > > > sorry, i actually meant "I don't see why not", for some reason, the "n= ot" > > was missed. Obviously I meant "why not", there was a "but" after it :-) > > > >> > >> > but we have lots of places calling swap_free(), we may > >> > have to change them all to call swap_free_nr(entry, 1); the other po= ssible > >> > way is making swap_free() a wrapper of swap_free_nr() always using > >> > 1 as the argument. In both cases, we are changing the semantics of > >> > swap_free_nr() to partially freeing large folio cases and have to dr= op > >> > "entry should be for the first subpage" then. > >> > > >> > Right now, the semantics is > >> > * swap_free_nr() for an entire large folio; > >> > * swap_free() for one entry of either a large folio or a small folio > >> > >> As above, I don't think the these semantics are important for > >> swap_free_nr() implementation. > > > > right. I agree. If we are ready to change all those callers, nothing > > can stop us from removing swap_free(). > > > >> > >> >> > >> >> > + > >> >> > + remain_nr =3D nr_pages; > >> >> > + p =3D _swap_info_get(entry); > >> >> > + if (p) { > >> >> > + for (i =3D 0; i < nr_pages; i +=3D batch_nr) { > >> >> > + batch_nr =3D min_t(int, SWAP_BATCH_NR, rema= in_nr); > >> >> > + > >> >> > + ci =3D lock_cluster_or_swap_info(p, offset)= ; > >> >> > + for (j =3D 0; j < batch_nr; j++) { > >> >> > + if (__swap_entry_free_locked(p, off= set + i * SWAP_BATCH_NR + j, 1)) > >> >> > + __bitmap_set(usage, j, 1); > >> >> > + } > >> >> > + unlock_cluster_or_swap_info(p, ci); > >> >> > + > >> >> > + for_each_clear_bit(j, usage, batch_nr) > >> >> > + free_swap_slot(swp_entry(type, offs= et + i * SWAP_BATCH_NR + j)); > >> >> > + > >> >> > + bitmap_clear(usage, 0, SWAP_BATCH_NR); > >> >> > + remain_nr -=3D batch_nr; > >> >> > + } > >> >> > + } > >> >> > +} > >> >> > + > >> >> > /* > >> >> > * Called after dropping swapcache to decrease refcnt to swap en= tries. > >> >> > */ > >> >> > >> >> put_swap_folio() implements batching in another method. Do you thi= nk > >> >> that it's good to use the batching method in that function here? I= t > >> >> avoids to use bitmap operations and stack space. > >> > > >> > Chuanhua has strictly limited the maximum stack usage to several > >> > unsigned long, > >> > >> 512 / 8 =3D 64 bytes. > >> > >> So, not trivial. > >> > >> > so this should be safe. on the other hand, i believe this > >> > implementation is more efficient, as put_swap_folio() might lock/ > >> > unlock much more often whenever __swap_entry_free_locked returns > >> > 0. > >> > >> There are 2 most common use cases, > >> > >> - all swap entries have usage count =3D=3D 0 > >> - all swap entries have usage count !=3D 0 > >> > >> In both cases, we only need to lock/unlock once. In fact, I didn't > >> find possible use cases other than above. > > > > i guess the point is free_swap_slot() shouldn't be called within > > lock_cluster_or_swap_info? so when we are freeing nr_pages slots, > > we'll have to unlock and lock nr_pages times? and this is the most > > common scenario. > > No. In put_swap_folio(), free_entries is either SWAPFILE_CLUSTER (that > is, nr_pages) or 0. These are the most common cases. > i am actually talking about the below code path, void put_swap_folio(struct folio *folio, swp_entry_t entry) { ... ci =3D lock_cluster_or_swap_info(si, offset); ... for (i =3D 0; i < size; i++, entry.val++) { if (!__swap_entry_free_locked(si, offset + i, SWAP_HAS_CACH= E)) { unlock_cluster_or_swap_info(si, ci); free_swap_slot(entry); if (i =3D=3D size - 1) return; lock_cluster_or_swap_info(si, offset); } } unlock_cluster_or_swap_info(si, ci); } but i guess you are talking about the below code path: void put_swap_folio(struct folio *folio, swp_entry_t entry) { ... ci =3D lock_cluster_or_swap_info(si, offset); if (size =3D=3D SWAPFILE_CLUSTER) { map =3D si->swap_map + offset; for (i =3D 0; i < SWAPFILE_CLUSTER; i++) { val =3D map[i]; VM_BUG_ON(!(val & SWAP_HAS_CACHE)); if (val =3D=3D SWAP_HAS_CACHE) free_entries++; } if (free_entries =3D=3D SWAPFILE_CLUSTER) { unlock_cluster_or_swap_info(si, ci); spin_lock(&si->lock); mem_cgroup_uncharge_swap(entry, SWAPFILE_CLUSTER); swap_free_cluster(si, idx); spin_unlock(&si->lock); return; } } } we are mTHP, so we can't assume our size is SWAPFILE_CLUSTER? or you want to check free_entries =3D=3D "1 << swap_entry_order(folio_order= (folio))" instead of SWAPFILE_CLUSTER for the "for (i =3D 0; i < size; i++, entry.val= ++)" path? > >> > >> And, we should add batching in __swap_entry_free(). That will help > >> free_swap_and_cache_nr() too. Chris Li and I actually discussed it before, while I completely agree this can be batched. but i'd like to defer this as an incremental patchset later to keep this swapcache-refault small. > > Please consider this too. > > -- > Best Regards, > Huang, Ying