From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id BE052C4725D for ; Fri, 19 Jan 2024 06:24:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3A1D36B008A; Fri, 19 Jan 2024 01:24:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 351776B008C; Fri, 19 Jan 2024 01:24:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1F2936B0092; Fri, 19 Jan 2024 01:24:30 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 0C2236B008A for ; Fri, 19 Jan 2024 01:24:30 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id D09C81601EE for ; Fri, 19 Jan 2024 06:24:29 +0000 (UTC) X-FDA: 81695071458.08.48D1C53 Received: from mail-pg1-f178.google.com (mail-pg1-f178.google.com [209.85.215.178]) by imf03.hostedemail.com (Postfix) with ESMTP id E786D20005 for ; Fri, 19 Jan 2024 06:24:27 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=Qro5mzNg; spf=pass (imf03.hostedemail.com: domain of zhouchengming@bytedance.com designates 209.85.215.178 as permitted sender) smtp.mailfrom=zhouchengming@bytedance.com; dmarc=pass (policy=quarantine) header.from=bytedance.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705645468; a=rsa-sha256; cv=none; b=N4Q0xKn9zrlMlSOlm2s5hw22VvHTYYva457kGOGpdX1gOZJycPkyyCWR2c/ALE6ZmWr1QB hv/i9DWTElyGsCuc/fv/t3oqKCpwqK5e3ac+x80qLOK9gRwRYORkEDDe38UdDwMvXme0jd vj1Szdv8KPAeAQcEjIjCrz27S/XZXSY= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=Qro5mzNg; spf=pass (imf03.hostedemail.com: domain of zhouchengming@bytedance.com designates 209.85.215.178 as permitted sender) smtp.mailfrom=zhouchengming@bytedance.com; dmarc=pass (policy=quarantine) header.from=bytedance.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705645468; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ezGigqCkcdld0LRuOuJDBfz/9AsfE2OTVy2IitNYYM8=; b=8aT/SLHvXE7KbVkRsmezLNQtx3mWs/GB8Pohc0v9GvuqAo9fPucTmWymTqs/yuz32KhFoV QEjDiEwbrVEIGmCDm45Uh4uU0DLTgqak+G1mbrnMuJLj6mrcA1ogb2uqKkhEyQXbVnL/LA zmXrbOhaiJEZiTWexz5Gvwpo+se8x0c= Received: by mail-pg1-f178.google.com with SMTP id 41be03b00d2f7-5ce6b5e3c4eso299753a12.2 for ; Thu, 18 Jan 2024 22:24:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1705645467; x=1706250267; darn=kvack.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=ezGigqCkcdld0LRuOuJDBfz/9AsfE2OTVy2IitNYYM8=; b=Qro5mzNg+oqWYTnja5DXJNKwH7qJ4HkD82mhJy/WiN6m+fjuRNXsYE3lXM+V9D3L1n S6VsBQO7QILs9x75Ok087MQfgqn7orcVUyQZzj0SMEr23UgIkCI8e/I9p9CNDmBi+RYf STTiq2igxO0AosCn7Kb+BVg4cJIJu+uyLAu9DUxAPFmEXliInq3J1vwJY1qVTlc/pbOZ tL61/gQamt5QD/9nLj8E1TKH25KwD4sbgEsq4GL2AAYjHh35Cw0MnSZnFgOiSX/mdDFG 9oy4FSV7rcMTNaR7w0XW38WZYdFfQAs6d41/y0yA40IAt2VMyovNeyGp0tCfyMz7az1S f9lA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705645467; x=1706250267; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ezGigqCkcdld0LRuOuJDBfz/9AsfE2OTVy2IitNYYM8=; b=ObUIARXkzD9BM1OZcy61QknKQ//aNUxl7FPO2YbRat4uPGk61Tg8tfb4yXDN6wbPqF 8oSyJcs7Ehg39bsxzFNMYQpiV0g0Zi3odYJEX/urV3lX4B22ACmEM9yMebh0bgpyqdMG 0+wSmiUmYZ1Q/g1iYgePrXOocehkebPNsUj24IbGXOV8Bj6WOt+OIuZYPrVv1mxZ0duO R23ik7wnikvotC66GsYHJksXzXV3xuh1VwQEMVVNkMICBSmDD3PFBObdoxAPajzb+wnv WKQRsua1omqkBdGtYz8hwFHCreyHYHiBWG+l8cEJ6QKulsLZVHT3X5TjyU8lya8MKkP1 RaJg== X-Gm-Message-State: AOJu0YzbgihgvIT5JiZuuU8E0YAgPI54paSUTycf4Z16onEkcOu0RgAh k8WBa6WSViRB+3I+7jlV+S20o50DpPydlbJi04dQaOozSweblkKYOAQ9HEPJZMGgoP98dAl+Y9T K X-Google-Smtp-Source: AGHT+IHbs1UCb6N4UA5U9mggCoxh/GqergCZhsihImGoe010eTwzBJXzkJPka6nGusHM57gdVMc67w== X-Received: by 2002:a17:902:c3d1:b0:1d7:19ec:2e55 with SMTP id j17-20020a170902c3d100b001d719ec2e55mr951130plj.59.1705645466629; Thu, 18 Jan 2024 22:24:26 -0800 (PST) Received: from [10.254.224.1] ([139.177.225.241]) by smtp.gmail.com with ESMTPSA id jf4-20020a170903268400b001d0d312bc2asm2301115plb.193.2024.01.18.22.24.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 18 Jan 2024 22:24:26 -0800 (PST) Message-ID: Date: Fri, 19 Jan 2024 14:24:21 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] mm/zswap: split zswap rb-tree Content-Language: en-US To: Nhat Pham Cc: Andrew Morton , Yosry Ahmed , linux-kernel@vger.kernel.org, Johannes Weiner , linux-mm@kvack.org, Chris Li References: <20240117-b4-zswap-lock-optimize-v1-0-23f6effe5775@bytedance.com> <20240117-b4-zswap-lock-optimize-v1-2-23f6effe5775@bytedance.com> From: Chengming Zhou In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: E786D20005 X-Stat-Signature: h9g5amoisk44rha16uzguh64ek7aa5bf X-Rspam-User: X-HE-Tag: 1705645467-784085 X-HE-Meta: U2FsdGVkX19yxmU/G4le211MeGNECuB1hFhOX4WcBlGVc6FyfBuOdZr4SB94MOAdF/xKxKzxdIKNTduzMtjsL2q8Gh+VATtokNysO2GgxJLDcNiah6o0BdmX/3b74yadz+IZzJDeWt0UhhoV4NPP4OcMX+4VL6UQH683wGWZttNf1WnykloZ4x64INr3Sluqc7tXTSxfV/PHBsfOqTcmgIcPEJFNoL2gd+ma8vHQuXyd3p8cdfTq6EpMDhDRVhCH6mkqLGnM9v2SzwbatTHp1xwiDXb5BonDm5lI/V8qpux+Aijd3t0N1nCb2Njyct6RpPEsIMZa20AxNMXk9PCTtshZjQwxSB1pVD3Lg8X09z/JC4x8l47z6fnVWQ834c5fKUtn0FPqBtFZQ8rj8sH0t3xBJZJwNMox7Sc7qiZgCSddmfFjj1AOOYnct9uUvSD6kv8CUzWZqpOf7qRGrUh0td19N3yqpYQ9tTyHoHSHvZJ3qYsZydikQ5shRPStiDUZ+uVS5d7rZ8TZwqayyMbe2M4G14l4IsryOzGOnTGcJLnH5TbbakY3IA84Nwg6c1uQ6Mo0S4FVXuM09TEiidxYf60uOmIH2E12rgqHr8+MfBES/GEtUwphC+8DqfsvVKoGWv/QG6FKilogNi+rIjqKX/WnDCwnxI98+zXZBYpRP+gpJ3Ozywy/0dtsDAWtsjf2X1cHJhoSLE5nl7Gr9ckdu9zyrer7kIqNmElHLPjS/fjO3vgUnFIvf4CvDT+F6cPlIqdXt+w/ud5vnnI0ObA8fChIwzY/zWGuEGb0f7dq+qkaCZ5uGA5JS0g3bRa6/dQLD6zfmReQ41tXQbkk0WW8SWQtzZ37nLCaEymeSgv/XXXJ1KI98zNmfT9SZnJvEgDoZ6i0CKWlMR8iDAuzWj+A2bjsJWC426EZjuHQiH8ZITpb/sCQR9gNLOxryO7l9wYjzMYtW3Al2OSzji8F076 xfVTyDzZ vdQsQc6ROB7IXNc736HIxoITWjWg6q0fPfWN/omRZxfssNULyQLr+jk/o34BrPSt9ZnA9HcWzT9r7KKmcUWXrgbM/THvAbSoGSOnSf2QTk91Mgag9OB5vlW1F4DgoFTwdhrKLqlAtrCJZNBBf+YsyZ+gH9TfOSMpw5k/1Z6gongPfhShDFOwsINl6N7GbqNQfFsgl/9YcVHxgqRky647dvZUM4H0a/ky2Hh2EkUO5vaXE79JbCT7J7JKmdN9S9ZI51H6XsJT8ipQoMPQSvMkoGGFn/2cKJi8MNpRFboJw7OgF+RWmyT7gy+/8Y98tw/8b1JPwr6g47NObEImF3wtKcaFizwTpbPNJhKe8yV2xhDeK45rmNNtae/ZT70CiYqpxIQ0IVW3xClQJmATqNqGunI89v8ro/oXW5QIv9czy9skk0RiZXM4aSZsql1BD3gw9O96PEKiwMQuzbZj0/Fh7+jHsJBkVGcYNF7rOzIyW2bg99U0= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 2024/1/19 03:24, Nhat Pham wrote: > On Wed, Jan 17, 2024 at 1:23 AM Chengming Zhou > wrote: >> >> Each swapfile has one rb-tree to search the mapping of swp_entry_t to >> zswap_entry, that use a spinlock to protect, which can cause heavy lock >> contention if multiple tasks zswap_store/load concurrently. >> >> Optimize the scalability problem by splitting the zswap rb-tree into >> multiple rb-trees, each corresponds to SWAP_ADDRESS_SPACE_PAGES (64M), >> just like we did in the swap cache address_space splitting. >> >> Although this method can't solve the spinlock contention completely, it >> can mitigate much of that contention. Below is the results of kernel build >> in tmpfs with zswap shrinker enabled: >> >> linux-next zswap-lock-optimize >> real 1m9.181s 1m3.820s >> user 17m44.036s 17m40.100s >> sys 7m37.297s 4m54.622s > > That's really impressive, especially the sys time reduction :) Well done. > Thanks! >> >> So there are clearly improvements. >> >> Signed-off-by: Chengming Zhou > > Code looks solid too. I haven't read the xarray patch series too > closely yet, but this patch series is clearly already an improvement. > It is simple, with existing precedent (from swap cache), and > experiments show that it works quite well to improve zswap's > performance. > > If the xarray patch proves to be even better, we can always combine it > with this approach (a per-range xarray?), or replace it with the > xarray. But for now: > > Acked-by: Nhat Pham > Right, I agree. We should combine both approaches.