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 8FB86C433FE for ; Mon, 7 Nov 2022 21:31:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 050A38E0001; Mon, 7 Nov 2022 16:31:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0004F6B0073; Mon, 7 Nov 2022 16:31:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E0A2E8E0001; Mon, 7 Nov 2022 16:31:17 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id CE5F96B0071 for ; Mon, 7 Nov 2022 16:31:17 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 9ACE7AB653 for ; Mon, 7 Nov 2022 21:31:17 +0000 (UTC) X-FDA: 80107942194.23.FF127C7 Received: from mail-pj1-f47.google.com (mail-pj1-f47.google.com [209.85.216.47]) by imf18.hostedemail.com (Postfix) with ESMTP id 472351C0005 for ; Mon, 7 Nov 2022 21:31:17 +0000 (UTC) Received: by mail-pj1-f47.google.com with SMTP id c15-20020a17090a1d0f00b0021365864446so11507334pjd.4 for ; Mon, 07 Nov 2022 13:31:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=b/a6s9FkrKvGz+jO1XUHUIKBmi/KNPRg8Hd8bDVTOKU=; b=jQVsyLbWNjAzBZlS5rCfJIEyzdnve7P7JHlITuQuT+Zf4knoTONtZrHuJgIHgzNi2j NMucZwWaLj6eeKX/EL/EWlmV5N4x62tCGA6FLUmWdfVbDn4Exv1axUTiVX6lRoedbWNM L+MXoxuyvMsHW6jrZGhIbz5f8K/dt2XVtR7BsPgahMsxmM/xSBg7qvjuDoFaySSd/VY+ TiIxgKPhZxMBYYlgucteiXLfK/NwTxTuFY6Fjkz7ImIrxYpIxj1wY3Js/7qjWFW5IAw5 YCkwEZP4PYGMJXHQMsgSN4MVzV35fP0/wYCoRO01oEi2bCSsTjZqJDb7s+sIpisCwTWW aGbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=b/a6s9FkrKvGz+jO1XUHUIKBmi/KNPRg8Hd8bDVTOKU=; b=M8gQqNkRudNVA/WhinzytHuqO8QRqxCLgOqoxOmxHAJU4bIKoRU6huTajb9pPHoKOD CMU9kS0Cevdjhq2Q34ls4oSiVCHXqH7YSx/He4N4+Yqo3SFv9xyWwqqyxjQ15RKcT4Vk UnjyuPy3vkGATkZoE6O1G3C3hlpHxPHcLXqLkOr+sA3wj6IbQhsWKLEkLgOlm1WjE6aQ i3V3ph8mYwsE5RbIwpirwEjxHMC1McVA7anKDGkXLsuTYWi7m91i29Qff/sk6Taaivsk xcITzRzkI6mrCShavkd7MYpB8Po2tqcs/Od+VaAqTC8GH0j3i/rSskl2pCGcrk77wZvt /mAQ== X-Gm-Message-State: ACrzQf1JBq/+UkaL1RX7GiJzZeeO98BGSJrPTpHGfIBsfTO5NYHI6C7o aCrjGqCE7xUokxlyiMsmv+Q= X-Google-Smtp-Source: AMsMyM6Lz2ApkCWLspkosq/SKhMG9Jxo9FRcsEiZhwlK0OjNypS59ubHiR5L26fr0AYPUysxJWRaoQ== X-Received: by 2002:a17:902:b089:b0:178:54cf:d692 with SMTP id p9-20020a170902b08900b0017854cfd692mr52085120plr.1.1667856676054; Mon, 07 Nov 2022 13:31:16 -0800 (PST) Received: from localhost (fwdproxy-prn-007.fbsv.net. [2a03:2880:ff:7::face:b00c]) by smtp.gmail.com with ESMTPSA id n126-20020a622784000000b0056b4c5dde61sm5083356pfn.98.2022.11.07.13.31.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Nov 2022 13:31:15 -0800 (PST) From: Nhat Pham To: senozhatsky@chromium.org Cc: hannes@cmpxchg.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, minchan@kernel.org, ngupta@vflare.org, akpm@linux-foundation.org, sjenning@redhat.com, ddstreet@ieee.org, vitaly.wool@konsulko.com Subject: Re: [PATCH 2/5] zsmalloc: Consolidate zs_pool's migrate_lock and size_class's locks Date: Mon, 7 Nov 2022 13:31:14 -0800 Message-Id: <20221107213114.916231-1-nphamcs@gmail.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=jQVsyLbW; spf=pass (imf18.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.216.47 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1667856677; a=rsa-sha256; cv=none; b=cmukAlSwM6qn5ugKgV6CR4XAxSx3h4N0M8n/6ZCBrU/mmL3cu6Ro+OTqsjkOVWWqW5BX/g lCWcoEv5trefWc9Z5OZ2ni2QQv0exhl4sqYreLNH+pMmoWNTtIXdoRHRji6tmgAjICLwcj IwXzPmGRVmkVSyrRnWJF8zKWo8evJgU= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1667856677; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=b/a6s9FkrKvGz+jO1XUHUIKBmi/KNPRg8Hd8bDVTOKU=; b=WEmvth5zOJTDQhufkUyX7FgKNohbQz8be12rrQ2/K4fZCALX305YBEi523+jejO8seO1t0 08RcRDVP/vttogKHI+sbmSnU+skMTzZvbWW4vEsdmjTsq8T2lNAb3/WsWBnGHlEOa2EiZw i77OEfR8qFMG8+IZECQVvcvqUmTph3s= X-Rspam-User: Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=jQVsyLbW; spf=pass (imf18.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.216.47 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 472351C0005 X-Stat-Signature: gaozr13pwg955o5ccnibazgqxgrpj4in X-HE-Tag: 1667856677-969227 X-Bogosity: Ham, tests=bogofilter, spamicity=0.001121, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: We have benchmarked the lock consolidation to see the performance effect of this change on zram. First, we ran a synthetic FS workload on a server machine with 36 cores (same machine for all runs), using this benchmark script: https://github.com/josefbacik/fs_mark using 32 threads, and cranking the pressure up to > 80% FS usage. Here is the result (unit is file/second): With lock consolidation (btrfs): Average: 13520.2, Median: 13531.0, Stddev: 137.5961482019028 Without lock consolidation (btrfs): Average: 13487.2, Median: 13575.0, Stddev: 309.08283679298665 With lock consolidation (ext4): Average: 16824.4, Median: 16839.0, Stddev: 89.97388510006668 Without lock consolidation (ext4) Average: 16958.0, Median: 16986.0, Stddev: 194.7370021336469 As you can see, we observe a 0.3% regression for btrfs, and a 0.9% regression for ext4. This is a small, barely measurable difference in my opinion. For a more realistic scenario, we also tries building the kernel on zram. Here is the time it takes (in seconds): With lock consolidation (btrfs): real Average: 319.6, Median: 320.0, Stddev: 0.8944271909999159 user Average: 6894.2, Median: 6895.0, Stddev: 25.528415540334656 sys Average: 521.4, Median: 522.0, Stddev: 1.51657508881031 Without lock consolidation (btrfs): real Average: 319.8, Median: 320.0, Stddev: 0.8366600265340756 user Average: 6896.6, Median: 6899.0, Stddev: 16.04057355583023 sys Average: 520.6, Median: 521.0, Stddev: 1.140175425099138 With lock consolidation (ext4): real Average: 320.0, Median: 319.0, Stddev: 1.4142135623730951 user Average: 6896.8, Median: 6878.0, Stddev: 28.621670111997307 sys Average: 521.2, Median: 521.0, Stddev: 1.7888543819998317 Without lock consolidation (ext4) real Average: 319.6, Median: 319.0, Stddev: 0.8944271909999159 user Average: 6886.2, Median: 6887.0, Stddev: 16.93221781102523 sys Average: 520.4, Median: 520.0, Stddev: 1.140175425099138 The difference is entirely within the noise of a typical run on zram. This hardly justifies the complexity of maintaining both the pool lock and the class lock. In fact, for writeback, we would need to introduce yet another lock to prevent data races on the pool's LRU, further complicating the lock handling logic. IMHO, it is just better to collapse all of these into a single pool-level lock.