Received: by 2002:ab2:2994:0:b0:1ef:ca3e:3cd5 with SMTP id n20csp690244lqb; Fri, 15 Mar 2024 03:58:01 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCXwpv6ct8bNM3chUfyNuKWfFopY76TCgv/WsnFlKiJr05mB9QQSEt11TZhVQMKOHKEoF8mmQH8wT3uXV16KPcXWKa6nh0BCIrVwVt+AbA== X-Google-Smtp-Source: AGHT+IEEP0DpOvfPirUI/CD1UAUc31KAJ3gcOmjus8E/RA9S53cQ6G+/DY93c4Fc//EZe1diTBMt X-Received: by 2002:a17:906:1d4b:b0:a45:270e:3617 with SMTP id o11-20020a1709061d4b00b00a45270e3617mr2974872ejh.27.1710500281587; Fri, 15 Mar 2024 03:58:01 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1710500281; cv=pass; d=google.com; s=arc-20160816; b=jENnmfbzriH1qfO+k4jwTKog8UIXxsGQCjG8QVW2c1HmknD26cBkoK+3sSJ7VEg9e9 ECJAXlYL3sguJjKQlZHZuONAg1yYwBjju7EKc5bxoOU/gW89GYzXeF3uuPbe8vXhgYQx LjypzYsz1ZwAdPs/b49CDuCeOv09xEyfLbLSED1/EIydXeWKqipMTyI7502KnWZZvyny WRXdSIQ7VySdaYKGqNZn68zm4nu4WZk5Zr7/7g/jIfiTPwTVElR8h9u7ShC+Uv78vFN4 ZiX/PyrjvPF3q2nYHq+M7MimplwAnjoa7Q31az1eEnMX1pp2ykdDfdTvK0leFDN3r94k HLyg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id; bh=GSD8IFCWnULcm0V/EVGK5+Cwf3Bbo9Kj4KV9PoPMNDU=; fh=HpqiYgQVDgscPZtnRbs41ZieW3kICYFANLrPz4oLB2o=; b=PfV6wTcOVIqDKkuovS29SqAqGc1m6jFOkdbIBryNeA/YmcKWEM7+s+e7TvIfX0EOnS mOt6t2XjnP/9afZc69SJcOmsbAbPeJ82/mala8KS3SyXU0XTIMTNQyFNuma8hPX68o3M NtajBW7BUKJe0bnd3dI47EVJCpnAoa7FRrpvOiECN9KCNEufDlsh8XxgzirScpu1Bos0 9ezbKR3jZXcHxrsumaNe7Ynjd6WuRkTlQ0KJb65lyDiqRi4JNuQF27iEr583owA1HRk4 5zpSjYdAB46Y4EjbgIKmM65c8bwGg1b0kjhtmc2juBVQYXnLJ9XzA8jaZVWQvkrtcPBz LtLg==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=arm.com dmarc=pass fromdomain=arm.com); spf=pass (google.com: domain of linux-kernel+bounces-104293-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-104293-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [2604:1380:4601:e00::3]) by mx.google.com with ESMTPS id hp16-20020a1709073e1000b00a4535a6cf2fsi1670349ejc.407.2024.03.15.03.58.01 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Mar 2024 03:58:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-104293-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=arm.com dmarc=pass fromdomain=arm.com); spf=pass (google.com: domain of linux-kernel+bounces-104293-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-104293-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.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 2D2661F222F9 for ; Fri, 15 Mar 2024 10:58:01 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 3671E199B0; Fri, 15 Mar 2024 10:57:54 +0000 (UTC) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 0332118E02 for ; Fri, 15 Mar 2024 10:57:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710500273; cv=none; b=W/dCYPGyGBUfLypoJEvzLibopwMieAOAsskG405EhE6cZZKN07/xrS6mTFmS4fnkJKvT4N949b1vqBss8gmLo5EPi5QwPRuDaxA50fJTYTO93Sj48Apa51hfrD6RLTMj/9jYT+t7z4q8BOJFZFvQ7jKT+hop+BlhO6p/Rk14mMg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710500273; c=relaxed/simple; bh=1aiyF0/x+T+SS07nzEDYgrQV2Q7jpEGhZTYThVJZ8Nc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=uhucnYZlrsnm23XTYjn4kONwTvn/NaKP3v56mHGUqVvINarAfTB7j2vm89d3FLTf2s02OIEv66nmTx1ScwJ9jWEZKDbN7g5QabEb0n7BTpK7nQNr7uvi3zIjEQjjU/gMCxwADOLICfKgEPXh7cupknqYGH1HOHSyOneRcvddy8o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 80A23C15; Fri, 15 Mar 2024 03:58:25 -0700 (PDT) Received: from [10.57.69.160] (unknown [10.57.69.160]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C71683F762; Fri, 15 Mar 2024 03:57:45 -0700 (PDT) Message-ID: <76c16222-78fd-4d96-b9f7-13264bb37747@arm.com> Date: Fri, 15 Mar 2024 10:57:44 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v3 2/5] mm: swap: introduce swap_nr_free() for batched swap_free() Content-Language: en-GB To: Chuanhua Han Cc: Barry Song <21cnbao@gmail.com>, akpm@linux-foundation.org, linux-mm@kvack.org, chengming.zhou@linux.dev, chrisl@kernel.org, david@redhat.com, hannes@cmpxchg.org, kasong@tencent.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, mhocko@suse.com, nphamcs@gmail.com, shy828301@gmail.com, steven.price@arm.com, surenb@google.com, wangkefeng.wang@huawei.com, willy@infradead.org, xiang@kernel.org, ying.huang@intel.com, yosryahmed@google.com, yuzhao@google.com, Chuanhua Han , Barry Song References: <20240304081348.197341-1-21cnbao@gmail.com> <20240304081348.197341-3-21cnbao@gmail.com> <499a60c6-eeb8-4bbd-8563-9717c0d2e43d@arm.com> <716bb29c-d2a2-4eef-b300-b037f08f458f@arm.com> From: Ryan Roberts In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 15/03/2024 08:34, Chuanhua Han wrote: > Ryan Roberts 于2024年3月14日周四 21:43写道: >> >> On 14/03/2024 13:12, Chuanhua Han wrote: >>> Ryan Roberts 于2024年3月12日周二 02:51写道: >>>> >>>> On 04/03/2024 08:13, Barry Song wrote: >>>>> 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 | 6 ++++++ >>>>> mm/swapfile.c | 35 +++++++++++++++++++++++++++++++++++ >>>>> 2 files changed, 41 insertions(+) >>>>> >>>>> diff --git a/include/linux/swap.h b/include/linux/swap.h >>>>> index 2955f7a78d8d..d6ab27929458 100644 >>>>> --- a/include/linux/swap.h >>>>> +++ b/include/linux/swap.h >>>>> @@ -481,6 +481,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); >>>> >>>> nit: In my swap-out v4 series, I've created a batched version of >>>> free_swap_and_cache() and called it free_swap_and_cache_nr(). Perhaps it is >>>> preferable to align the naming schemes - i.e. call this swap_free_nr(). Your >>>> scheme doesn't really work when applied to free_swap_and_cache(). >>> Thanks for your suggestions, and for the next version, we'll see which >>> package is more appropriate! >>>> >>>>> 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); >>>>> @@ -561,6 +562,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 3f594be83b58..244106998a69 100644 >>>>> --- a/mm/swapfile.c >>>>> +++ b/mm/swapfile.c >>>>> @@ -1341,6 +1341,41 @@ void swap_free(swp_entry_t entry) >>>>> __swap_entry_free(p, entry); >>>>> } >>>>> >>>>> +/* >>>>> + * Called after swapping in a large folio, batched free swap entries >>>>> + * for this large folio, entry should be for the first subpage and >>>>> + * its offset is aligned with nr_pages >>>>> + */ >>>>> +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 = swp_type(entry); >>>> >>>> nit: checkpatch.py will complain about bare "unsigned", preferring "unsigned >>>> int" or at least it did for me when I did something similar in my swap-out patch >>>> set. >>> Gee, thanks for pointing that out! >>>> >>>>> + unsigned long offset = swp_offset(entry); >>>>> + DECLARE_BITMAP(usage, SWAPFILE_CLUSTER) = { 0 }; >>>> >>>> I don't love this, as it could blow the stack if SWAPFILE_CLUSTER ever >>>> increases. But the only other way I can think of is to explicitly loop over >>>> fixed size chunks, and that's not much better. >>> Is it possible to save kernel stack better by using bit_map here? If >>> SWAPFILE_CLUSTER=512, we consume only (512/64)*8= 64 bytes. >> >> I'm not sure I've understood what you are saying? You're already using >> DECLARE_BITMAP(), so its already consuming 64 bytes if SWAPFILE_CLUSTER=512, no? >> >> I actually did a bad job of trying to express a couple of different points: >> >> - Are there any configurations today where SWAPFILE_CLUSTER > 512? I'm not sure. >> Certainly not for arm64, but not sure about other architectures. For example if >> an arch had 64K pages with 8192 entries per THP and supports SWAP_THP, that's 1K >> for the bitmap, which is now looking pretty big for the stack. > I agree with you.The current bit_map grows linearly with the > SWAPFILE_CLUSTER, which may cause the kernel stack to swell. > I need to think of a way to save more memory . >> >> - Would it be better to decouple stack usage from SWAPFILE_CLUSTER and instead >> define a fixed stack size (e.g. 64 bytes -> 512 entries). Then free the range of >> entries in batches no bigger than this size. This approach could also allow >> removing the constraint that the range has to be aligned and fit in a single >> cluster. Personally I think an approach like this would be much more robust, in >> return for a tiny bit more complexity. > Because we cannot determine how many swap entries a cluster has in an > architecture or a configuration, we do not know how large the variable > needs to be defined? My point is that we could define a fixed size, then loop through the passed in range, operating on batches of that fixed size. You could even take into consideration the cluster boundaries so that you take the correct lock for every batch and can drop the "must be naturally aligned, must be no bigger than cluster size" constraint. >> >>>> >>>>> + >>>>> + /* all swap entries are within a cluster for mTHP */ >>>>> + VM_BUG_ON(offset % SWAPFILE_CLUSTER + nr_pages > SWAPFILE_CLUSTER); >>>>> + >>>>> + if (nr_pages == 1) { >>>>> + swap_free(entry); >>>>> + return; >>>>> + } >>>>> + >>>>> + p = _swap_info_get(entry); >>>> >>>> You need to handle this returning NULL, like swap_free() does. >>> Yes, you're right! We did forget to judge NULL here. >>>> >>>>> + >>>>> + ci = lock_cluster(p, offset); >>>> >>>> The existing swap_free() calls lock_cluster_or_swap_info(). So if swap is backed >>>> by rotating media, and clusters are not in use, it will lock the whole swap >>>> info. But your new version only calls lock_cluster() which won't lock anything >>>> if clusters are not in use. So I think this is a locking bug. >>> Again, you're right, it's bug! >>>> >>>>> + for (i = 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)); >>>>> +} >>>>> + >>>>> /* >>>>> * Called after dropping swapcache to decrease refcnt to swap entries. >>>>> */ >>>> >>>> Thanks, >>>> Ryan >>>> >>>> >>> >>> >> > >