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 280C8390237 for ; Sat, 25 Jul 2026 03:57:38 +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=1784951860; cv=none; b=npVHzUwpooMRGZ5i6WeukLqEiutRx1CX+NHdL/aWLN/4OcVFI5ZGzx4mpA3SOvEYFIOckdGOilc6fx65AiuGloH5/TGq+qRhy2NS2bFtO+0MIBnffWyHRb/xVa5l5j1PFm2Km+udunYgu9I+Uytxuwt2b7n4lbHRXzSt+jyM3Gg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784951860; c=relaxed/simple; bh=xnyxIQEEHa955VUO3pTu3A+m0Caa+/SWBF4vNvYMzmI=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=MoH/xMqfESXg3aaMz96/MVzpPOKsPWuLsFcP0thd4mgOkYknv5PA+YK0QRIQ07gGP4TVXM1JEZVXzS3/c3yi56YFD8xZgrilMcNVVm6NClKGpZQHnuWgk/O+kV5H+VwPJ32SwvWt9ckHK1tslsXHYe8pE5XBfjuBrVMR9FZ2tfU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=VawCDvWX; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="VawCDvWX" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B0E8A1F000E9; Sat, 25 Jul 2026 03:57:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784951858; bh=k27M1ifd+dlCcvlTjTpk5IYjKpC55yJlcfhppDsrzdk=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=VawCDvWXILXVBYEk9LeoNq5jQOG6vtTu0/IQgEP0y9WMso66ndvfswCLyjgJngG5Q sn983AGJTIMjEZNI9lpv10NOkD1ViTHdqcuHAAsEm92HOA7LYvJLnx0419ZwcFOqBY JD/JGsjtob3YZp7lciyvTBIYj4Ro16V18ToWdK8Xyewl9B5lMjWYIJd1de8FfX8/p7 3UlnFfR5Cmjp16IuMUKQqL7Z8ARJe2oAeduCyZWB4VWKAvCeoP3vJnWDLfC2IYrBEL a5/nryA4cusXJ81RnvR9y7i0UFEMwMVJbpnqZ+KMpUC06/O+qyZHIabU5mGaLoktzR BeQ5VpQhAwhxg== From: "Barry Song (Xiaomi)" To: senozhatsky@chromium.org Cc: akpm@linux-foundation.org, baohua@kernel.org, haowenchao22@gmail.com, haowenchao@xiaomi.com, joshua.hahnjy@gmail.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, minchan@kernel.org, nphamcs@gmail.com Subject: Re: [PATCH v6 0/4] mm/zsmalloc: reduce lock contention in zs_free() Date: Sat, 25 Jul 2026 11:57:33 +0800 Message-Id: <20260725035733.53241-1-baohua@kernel.org> X-Mailer: git-send-email 2.39.3 (Apple Git-146) In-Reply-To: References: 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: 8bit On Fri, Jul 24, 2026 at 12:55 PM Sergey Senozhatsky wrote: > > Apologies for the delay. > > On (26/06/27 21:36), Andrew Morton wrote: > [..] > > > Raspberry Pi 4B (4-core ARM64 Cortex-A72): > > > > > >   mode        Base       Patched     Speedup > > >   single      59.0ms     56.0ms      1.05x > > >   multi 2p    94.6ms     66.7ms      1.42x > > >   multi 4p    202.9ms    110.6ms     1.83x > > > > > > x86 (20-core Intel i7-12700, 16 concurrent processes): > > > > > >   mode        Base       Patched     Speedup > > >   single      11.7ms     9.8ms       1.19x > > >   multi 2p    24.1ms     17.2ms      1.40x > > >   multi 4p    63.0ms     45.3ms      1.39x > > > > Well that's a nice result. > > Indeed. > > > Sashiko AI review said ....  nothing.  I don't recall seeing that > > before ;) > > grep-ing the code, I wonder if we maybe want to tweak some comments. > Namely, zs_page_migrate() says: > >         The pool migrate_lock protects the race between zpage migration >         and zs_free > > which is not entirely true anymore, as zs_free() has a lockless path > that doesn't take pool look (when ZS_OBJ_CLASS_BITS permit). > > Likewise, __zs_compact() says the following about pool migrate_lock: > >         protect the race between zpage migration and zs_free > > None of these are critical, very minor. Does it look good to you if we squash the below change into patch2/4: >From 49091bd19445c8927ae063042bc7394e7cc359c0 Mon Sep 17 00:00:00 2001 From: "Barry Song (Xiaomi)" Date: Sat, 25 Jul 2026 11:45:09 +0800 Subject: [PATCH] mm: zsmalloc: update the comment about pool lock Update the comment to reflect that `zs_free()` can be lockless when `ZS_OBJ_CLASS_BITS` applies. Suggested-by: Sergey Senozhatsky Signed-off-by: Barry Song (Xiaomi) --- mm/zsmalloc.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c index 3d566a3ee96f..b5eadee0e8f0 100644 --- a/mm/zsmalloc.c +++ b/mm/zsmalloc.c @@ -1865,8 +1865,8 @@ static int zs_page_migrate(struct page *newpage, struct page *page, pool = zspage->pool; /* - * The pool migrate_lock protects the race between zpage migration - * and zs_free. + * The pool migrate_lock protects against races between zpage migration + * and zs_free(), but only when ZS_OBJ_CLASS_BITS does not apply. */ write_lock(&pool->lock); class = zspage_class(pool, zspage); @@ -2045,8 +2045,9 @@ static unsigned long __zs_compact(struct zs_pool *pool, unsigned long pages_freed = 0; /* - * protect the race between zpage migration and zs_free - * as well as zpage allocation/free + * Protect against races between zpage migration and zs_free() + * (only when ZS_OBJ_CLASS_BITS does not apply), as well as + * zpage allocation and free. */ write_lock(&pool->lock); spin_lock(&class->lock); -- 2.39.3 (Apple Git-146)