From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 ED3B340F73D for ; Fri, 7 Aug 2026 21:42:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786138979; cv=none; b=PMPaq5Yj+XYx5tMMLADm5DHmKhr/h2BHbuzkIY4BHe0wPn79P1zzQpqLOY4ElV6I/eInnapEHzdf2dMDA7ZofeDdf2hSCgAH/MmnvV08fEtzzuHE24V+OuqTqAQYhwijhHupMDpvshMrmDdW2w/nAt0d/iLh1a0xNNWayBmDA6Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786138979; c=relaxed/simple; bh=qRxWys1par8wDGndBytbrlnO8pGncafjtYYe08KZQg8=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=Gpds5z4a2eWTBZdspJeMDee21VpRZ0Sp3PJRAvNTW95DwuqnnNO/USsJUCJyXZ5p9/pMTRNXBXzzE95pS7MmjcqQX79HeZLxx5eroHtgH8jhzvcoJs4OGshV4AIE+u3gfD7WhMS9W1vf38oeJWKdtxnBDmQYsX7JVsuXj3bPn4Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=wP//6lGK; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="wP//6lGK" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4E1CA1F000E9; Fri, 7 Aug 2026 21:42:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1786138977; bh=V5Weo6gzWFeGsLCsHrlTVQmPSXk+S4ozjr38z5Dj6Us=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=wP//6lGKsVrokbJLjPmhaKcE7zZRoPqmDXQXP1gb6YhD5KjbQHNQOPEXJWY9zYucb Tg5GDWocjRIPdCaFvIh2uiE8WnSYPq2xQhsVXjl543kl2dwdeoSaba1xeAN9Dd0ABp RQjqdM6wgd5EsHD5fvHWB7j7yA3mpGqYq/jTznyw= Date: Fri, 7 Aug 2026 14:42:56 -0700 From: Andrew Morton To: Baoquan He Cc: Youngjun Park , 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: <20260807144256.6fbdfd15f7ed4f518af7929f@linux-foundation.org> In-Reply-To: References: <20260806193228.458685-1-youngjun.park@lge.com> <20260806130655.420e16bf621b580cc5f08040@linux-foundation.org> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) 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-Transfer-Encoding: 7bit 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.