Received: by 2002:ab2:69cc:0:b0:1f4:be93:e15a with SMTP id n12csp1296604lqp; Mon, 15 Apr 2024 01:53:48 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCXTWFAMRqZbcZ712BvEOkneVaq3LZozG2qA5BmVMgUAdZARqPxxkcefHIp2BdAe27+Nqlx58OU9CwC8hOCDh1phyCDbl0dJjHXIZ5ZXUA== X-Google-Smtp-Source: AGHT+IHAbALWo/m3pWHOk/bhyCv9D4KUbNRUTW+WAWcKdwTqGZrnk8TuhfcxRZDRSB9F2dsyhOse X-Received: by 2002:a17:906:2988:b0:a52:2486:299f with SMTP id x8-20020a170906298800b00a522486299fmr5981888eje.71.1713171227869; Mon, 15 Apr 2024 01:53:47 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1713171227; cv=pass; d=google.com; s=arc-20160816; b=d8dcWkQMt/tcTfUcqQDBNjtnse6BpB/lV9deZw7JGtDxTowPqhzvZAGKmXBHoetpbA 3eIaMBIcpctaDSu+x79dsqelPj4DHlC7awtGRQFuKIjMhk3St+21ujhJbKdJSWSg9aSX yVKfS/QmuXEfNwGRhxaefmNSrTEbPUSwemMudoHdFVRnIcGPD8TQ3IIZJyhrMXf6MKjA IcC0WVAy8RI4/lv6SHEslJ+0txODZGVNQDIyLEmSHlNfcdzjJplYjE3956HEyrVokDes ECPt6zBTfWfAZrS/CxOMWAO18x5Ul1tIc3CEfN2JFwyVCJkFbMtcAOlJPut3qYmKSdxT IuPg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:dkim-signature; bh=/kaEjs7ArCRIWMtW+EMWjOIWjvM1eDgGzEhPkziVyQc=; fh=f5iXLJJ6ipNm5uL8hOx5AzNVi0bymIHPviXd+spkTi0=; b=EgVMMvkb0+iGLay6/0kW2FSgB3Q5JSkZWW57wO5GZe+5ZJ/NNqiqfYTEmP4CRUNB2e A70BjIkAcSTCBsd5dp45vzM+fMt5MVQoaPcjT1pzEaM8Dnz/9ROeQZB0f7R8JwjARFQ2 2OO3xcl/zCAtCUsrXn/RUDxCiDLHjMj3JUVua4nVGFOREtiBz5KuMMmmYQTjIunKwSbH OljfmWw1INgQ0lMfr124aeY2tDFqL6m4PyCuGJFpt3FqPidzo1XhPWjhLp9I9Dbfn0Ke VV1EmUlrFBm8dZq1sMurvbq8yzj7NZiDHI56FvXPZroNxHGG0rZ1+hL4hy2jguB4NYS1 sW3g==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=ZjPF03SG; arc=pass (i=1 spf=pass spfdomain=intel.com dkim=pass dkdomain=intel.com dmarc=pass fromdomain=intel.com); spf=pass (google.com: domain of linux-kernel+bounces-144803-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-144803-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id hd19-20020a170907969300b00a5224b85a31si4180552ejc.772.2024.04.15.01.53.47 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Apr 2024 01:53:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-144803-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=ZjPF03SG; arc=pass (i=1 spf=pass spfdomain=intel.com dkim=pass dkdomain=intel.com dmarc=pass fromdomain=intel.com); spf=pass (google.com: domain of linux-kernel+bounces-144803-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-144803-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 7042C1F220FB for ; Mon, 15 Apr 2024 08:53:47 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 60A524085C; Mon, 15 Apr 2024 08:53:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="ZjPF03SG" Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 83D8D40849 for ; Mon, 15 Apr 2024 08:53:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.8 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713171211; cv=none; b=M0kkz/8iEibrTtpkAYa6tLfpoSL/jvReRxUfW7v1EbyLR7ZVQ3ODItNsHEh6P6taaisqSgRbprQ9o3+30SvYFocPZZTRQ82OfIZ8m3QnyCTBC5xygTxdVtidr3MmrzaDrDxqTH2He9SE6vz06AW2CnRVNLxxBUGj+LaX+xNL84s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713171211; c=relaxed/simple; bh=EsMKr0w1TpAbSp218Fj9Hstk7+msxZwgrultS4LOyrA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=loXYQgtemEEBBo/kXtQH1ZMamHpsq6J7MVYz7iS4z+xiMoQxLurG/80fbdpEZX+cNG7rv5KAgonodZy+NzLn7OTp1fU9co4Lmnbq2f4ABSOE6GIsxFht4kzbJLYUjDt4kBYcWFGeniaCdf0o3tQKYEHamSunt+NpnJbjIRXB1i0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=ZjPF03SG; arc=none smtp.client-ip=192.198.163.8 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1713171209; x=1744707209; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version:content-transfer-encoding; bh=EsMKr0w1TpAbSp218Fj9Hstk7+msxZwgrultS4LOyrA=; b=ZjPF03SGdzeil5tOEuKuOHAeWPHl+AE3VXDFV0ZazU8KpASaqNYZwRUi f0QJANp5pjaopNoOXwhcriIxS22QJwKUrnGewwy7YvyIJb4PoeGyyQh7c zdUOT+VW6NBpHhBysm7QfEO9a3M2lVsO/dubil34keuFeiiUCzew8iF4/ zk1McC1xu+asyCshYY/ZlFN4rjkppPpJiT61nyb+FMDhxcd7Yp++uIlfB mzF9CEnALbxTCGjC8T4Hada0IqdQO121hL92ERLhL94D85FNj4alVj6WN oU037COw2PCRnZqHQbEYemW+NAEaGA2U5inOiDx34RNyJNyIZK8yHozs+ w==; X-CSE-ConnectionGUID: s40spf1RTMe03njR9ff27g== X-CSE-MsgGUID: Zfl2DNzMRrOqlkK2Xxq0bg== X-IronPort-AV: E=McAfee;i="6600,9927,11044"; a="26061711" X-IronPort-AV: E=Sophos;i="6.07,202,1708416000"; d="scan'208";a="26061711" Received: from fmviesa002.fm.intel.com ([10.60.135.142]) by fmvoesa102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Apr 2024 01:53:28 -0700 X-CSE-ConnectionGUID: xc71KNUzT+GdzOwCjmRREw== X-CSE-MsgGUID: yksLixeZTH+GuyIClr+Y6Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,202,1708416000"; d="scan'208";a="45124998" Received: from unknown (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by fmviesa002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Apr 2024 01:53:24 -0700 From: "Huang, Ying" To: Barry Song <21cnbao@gmail.com> 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 Subject: Re: [PATCH v2 1/5] mm: swap: introduce swap_free_nr() for batched swap_free() In-Reply-To: (Barry Song's message of "Mon, 15 Apr 2024 20:34:36 +1200") 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> Date: Mon, 15 Apr 2024 16:51:31 +0800 Message-ID: <87bk6b2elo.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 t= he whole >> >> > folio. To avoid frequently acquiring and releasing swap locks, it i= s 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 the >> >> > + * maximum kernel stack usage. >> >> > + */ >> >> > +#define SWAP_BATCH_NR (SWAPFILE_CLUSTER > 512 ? 512 : SWAPFILE_CLU= STER) >> >> > + >> >> > +/* >> >> > + * Called after swapping in a large folio, >> >> >> >> IMHO, it's not good to document the caller in the function definition. >> >> Because this will discourage function reusing. >> > >> > ok. right now there is only one user that is why it is added. but i ag= ree >> > we can actually remove this. >> > >> >> >> >> > batched free swap entries >> >> > + * for this large folio, entry should be for the first subpage and >> >> > + * 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 discontig= uous >> > and not-aligned offsets, we can't pass entry as the parameter, we shou= ld >> > 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_CLU= STER); >> >> > + >> >> > + if (nr_pages =3D=3D 1) { >> >> > + swap_free(entry); >> >> > + return; >> >> > + } >> >> >> >> Is it possible to unify swap_free() and swap_free_nr() into one funct= ion >> >> 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 term. > > sorry, i actually meant "I don't see why not", for some reason, the "not" > 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 poss= ible >> > 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 drop >> > "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, remain= _nr); >> >> > + >> >> > + ci =3D lock_cluster_or_swap_info(p, offset); >> >> > + for (j =3D 0; j < batch_nr; j++) { >> >> > + if (__swap_entry_free_locked(p, offse= t + 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, offset= + 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 entr= ies. >> >> > */ >> >> >> >> put_swap_folio() implements batching in another method. Do you think >> >> that it's good to use the batching method in that function here? It >> >> 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. > 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_CA= CHE)) { > 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); > } > >> >> And, we should add batching in __swap_entry_free(). That will help >> free_swap_and_cache_nr() too. Please consider this too. -- Best Regards, Huang, Ying