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 780AE13A244 for ; Sun, 28 Jun 2026 04:36:01 +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=1782621362; cv=none; b=sD4DERKB1wwbopcGHncQgfTqO9TnI57RWln+A4FNy4f0N5LR0s+/+g/MgPWA2ge0XumBZvMdTs57OJHuNj6g5hj5GWdKOXeAn3fAli31wpUnStwpMVDXmVpZ+jRlAnjW2ORA8Wt/1rit1o0QC1g0fzxZfxvNwEnavp7U72d0w4c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782621362; c=relaxed/simple; bh=2G48aPh7cz3b4ItDI7zXOcYW3H7dQUHJfY24j6kGTvs=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=RZjnuPfHn6mFC8LFsilo4mzJPiPTW7aTz8M6ljWH3uRqZCxcZO0cngD5W0FWBtlnsYapS8nwTj6akdJEsScAzavKsenKo0KeDBU1G+X1AwrilLTyCreem7PbHgPp+oxg2DqGWl3b0Y6MxTT8Uzzef2d3WJT4kclOAJrKKs3+Mvc= 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=LhHpJH0r; 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="LhHpJH0r" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8DA291F000E9; Sun, 28 Jun 2026 04:36:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1782621360; bh=/Wjl+dxNDyYjsMYaLZcgEdyYxld6KBRJroBN1TfCk0w=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=LhHpJH0rvmw3IgvaFZDaHqDd7tyjuwuh6THoTUFV0BGWlmbT6aWUi7YHoOEBCCKgD zCWuLWmpntHhB0m9hCcyMkMH2n9aMcm8MZwdhDiIj4kaBtpe1RADMuILAKz/7xyYvr e4lj7rY5w7ix/b2csStP3rSoTvdWEhkPKzHMRB8Q= Date: Sat, 27 Jun 2026 21:36:00 -0700 From: Andrew Morton To: Wenchao Hao Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Minchan Kim , Sergey Senozhatsky , Nhat Pham , Joshua Hahn , Barry Song , Wenchao Hao Subject: Re: [PATCH v6 0/4] mm/zsmalloc: reduce lock contention in zs_free() Message-Id: <20260627213600.eb072ba84382807a8242efc9@linux-foundation.org> In-Reply-To: <20260626015003.2965881-1-haowenchao22@gmail.com> References: <20260626015003.2965881-1-haowenchao22@gmail.com> 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, 26 Jun 2026 09:49:59 +0800 Wenchao Hao wrote: > From: Wenchao Hao > > This series reduces lock contention in zs_free(), which dominates the > unmap path under memory pressure on Android (LMK kills) and on x86 > servers running zswap-heavy workloads. > > The current zs_free() takes pool->lock (rwlock, read side) just to > look up the size_class for a handle, then takes class->lock and holds > it across __free_zspage() which can call into the buddy allocator and > acquire zone->lock. Two costs follow: > > * pool->lock reader-counter cacheline bouncing among concurrent > zs_free() callers. > * class->lock held across folio_put(), so any zone->lock wait > fans out to every other zs_free() on the same class. > > The series tackles both: > > Patch 1: encode size_class index into obj alongside PFN and obj_idx, > so zs_free() can locate the class without pool->lock. > Patch 2: drop pool->lock from zs_free() on 64-bit; 32-bit unchanged. > Patch 3: move zspage page-freeing out of class->lock. > Patch 4: document the three free_zspage helper variants that result > from the split in patch 3. > > Performance results: > > Test: each process independently mmap 256MB, write data, madvise > MADV_PAGEOUT to swap out via zram (lzo-rle), then concurrent munmap. > > 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. Sashiko AI review said .... nothing. I don't recall seeing that before ;) I'll add this series to mm.git for the next step, thanks.