From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lgeamrelo13.lge.com (lgeamrelo13.lge.com [156.147.23.53]) (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 7C5A5BA3D for ; Sat, 8 Aug 2026 15:53:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=156.147.23.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786204416; cv=none; b=MmnWO5tLXuBljvM+1HHUaKXcjuaeZjBSttQyn568iUJw7pGSZ+T563lcd00b0uekInb2vYfE98lhfy77BSTCupLVZbmkthysr+NiMgyGawTU1nT2s2N80/zNpaZ3NQ8X9n9VdgAy/bB8BySVMGutd7B0CJUXVqVaQHK9nMdyKMo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786204416; c=relaxed/simple; bh=9VLD/wTFbYPGEFC39JHerj9ecnP8OicUuuUgyt4iGx0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=dRMN9YqdewsWxgLZSGzpf3HaHUxAOvSDDd3tsxa590yQcbsFMu3Ke9Ov17O/7WU9aOzkcjKnyRE/u3/pPqaVEHJvsFmV2jIz1t9V5+/QoQIyqAB5iqh9156+3WEJE818RwneD/UrNIIBbcpYriTcb2fyf2feKLmYoUmJVFMeiKE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lge.com; spf=pass smtp.mailfrom=lge.com; arc=none smtp.client-ip=156.147.23.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lge.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=lge.com Received: from unknown (HELO lgeamrelo02.lge.com) (156.147.1.126) by 156.147.23.53 with ESMTP; 9 Aug 2026 00:53:23 +0900 X-Original-SENDERIP: 156.147.1.126 X-Original-MAILFROM: youngjun.park@lge.com Received: from unknown (HELO yjaykim-PowerEdge-T330) (10.177.112.156) by 156.147.1.126 with ESMTP; 9 Aug 2026 00:53:23 +0900 X-Original-SENDERIP: 10.177.112.156 X-Original-MAILFROM: youngjun.park@lge.com Date: Sun, 9 Aug 2026 00:53:23 +0900 From: Youngjun Park To: Andrew Morton Cc: Baoquan He , Chris Li , Kairui Song , Kemeng Shi , Nhat Pham , Barry Song , her0gyugyu@gmail.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 0/2] mm/swap: skip empty clusters in the swapoff scan Message-ID: References: <20260806193228.458685-1-youngjun.park@lge.com> <20260806130655.420e16bf621b580cc5f08040@linux-foundation.org> <20260807144256.6fbdfd15f7ed4f518af7929f@linux-foundation.org> 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=us-ascii Content-Disposition: inline In-Reply-To: <20260807144256.6fbdfd15f7ed4f518af7929f@linux-foundation.org> On Fri, Aug 07, 2026 at 02:42:56PM -0700, Andrew Morton wrote: > On Fri, 7 Aug 2026 16:42:22 +0800 Baoquan He wrote: > > > > I have no measured times yet, since that case has to be set up on purpose. > > > What I did is the arithmetic for the case that skips best, > > > For example 1T of swap with 256M slots with SWAPFILE_CLUSTER = 512 > > > and everything free but the far end: > > > > > > - today: 256M table reads > > > - with the skip: 512K counter reads > > > > > > Maybe just use time to measure swapoff time consuming, just like below > > as I did on a kvm guest, I guess a bare metal machine with larger system > > ram could be more obvious? > > > > root@fedora:~# free -h > > total used free shared buff/cache available > > Mem: 3.8Gi 181Mi 3.6Gi 924Ki 72Mi 3.7Gi > > Swap: 2.0Gi 18Mi 2.0Gi > > root@fedora:~# time swapoff /dev/vdb > > > > real 0m0.101s > > user 0m0.001s > > sys 0m0.017s > > root@fedora:~# swapon /dev/vdb > > root@fedora:~# time swapoff /dev/vdb > > > > real 0m0.014s > > user 0m0.003s > > sys 0m0.001s > > > > Not sure if Andrew is asking for this. > > I think it's helpful to include such info. The audience for changelogs > is more than swap developers! It's also an MM maintainer and -stable > maintainers and other people who are all wondering "should I backport > this for my users". Let's give them the means to determine that. Hello Andrew Here is the experiment. 7.2-rc5, fill a 1 TiB swap up to some amount, then swapoff. What is left sits at the top of what was filled, so every slot below it is free. Those entries are in the swap cache and cheap to free, so the search is most of the time. In short, best scenario my patch shows improvement. Medians over 11 pairs at 32 and 128 GiB, 3 pairs at 256 and 512. filled swapoff old new 32 GiB 92.4ms 66.3ms 128 GiB 157.6ms 94.4ms 256 GiB 209.7ms 63.8ms 512 GiB 391.8ms 73.4ms old grows with how much was filled, new does not. In the ordinary case swap still holds real data and swapoff spends its time reading it back. I tested 4 GiB on an 8 GiB device, where the scan is 1.4% of try_to_unuse(), and there is no difference either way. meaning no regression Thanks! Youngjun