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 75B51C4167B for ; Fri, 8 Dec 2023 00:43:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 04B816B0085; Thu, 7 Dec 2023 19:43:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id F3DE36B0087; Thu, 7 Dec 2023 19:43:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E05C66B0088; Thu, 7 Dec 2023 19:43:13 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id CF3986B0085 for ; Thu, 7 Dec 2023 19:43:13 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 826BD160315 for ; Fri, 8 Dec 2023 00:43:13 +0000 (UTC) X-FDA: 81541801866.19.F2A8529 Received: from mail-io1-f48.google.com (mail-io1-f48.google.com [209.85.166.48]) by imf25.hostedemail.com (Postfix) with ESMTP id 9E3B2A0028 for ; Fri, 8 Dec 2023 00:43:11 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=mjsunuZ2; spf=pass (imf25.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.166.48 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=1701996191; a=rsa-sha256; cv=none; b=271LvyqeKjh8R3UqAuaUDSu6vIHR+7XUg7VWFZBGVa2Cjmfn2V/Mqa30oFbABIpUK/rqME xUVhGoVoJqgxOvKwPLHbtjhM58klVAaTHsaUEBA6LCWumLkN23ofaD+/oxfY7SfXLFzcYm sXHIhnHhfBaoURDjKRLFVmyozWBIhDU= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=mjsunuZ2; spf=pass (imf25.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.166.48 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1701996191; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=8OQ4qcJBnrVu5qdEda2Vkc1e736jChzDqNzRg++7jp4=; b=ICx6FPbNyweHoPerXWqni/Yl271kXeuAl3nuUv6aewb1daTCVbk9OoG6zoOFq2G44K2Ctd y69tA4HvSamx15sxFN6Dv1HslrTaGWj14jhZhuZgCkz92axrYGnZ8/IaJ/SdINZOKEki1x c3xAKuttmZVyK6qQKBzsBMleMcno6mU= Received: by mail-io1-f48.google.com with SMTP id ca18e2360f4ac-7b3b819f8a3so70338339f.1 for ; Thu, 07 Dec 2023 16:43:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701996191; x=1702600991; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=8OQ4qcJBnrVu5qdEda2Vkc1e736jChzDqNzRg++7jp4=; b=mjsunuZ216Dou9b3A2HTY+2/kF3U5MkMdpxyauEbTiY8F8FhRGGl+3bRGxcql7q7yQ 3UbTeW43RcoX5nHQUeBZx24oZ0mV0qPIN8fUzMNybNyxcM3am/w6qE+jNH/npR36BXHF tOh8SMG2k9eo7NCOBkacxYl3QZWexEX7deQfFKXKj2g+w05ECyxQPclipJnKueDqKk5I iVs0rBuOixR5Y2xNOkwPQqFIb8YchlW9aI7F9hBDlgl3LcZM0+cMrdKIxyGi4IvpfyuB Kf7AIpt5R5uTFW9E06zfe16S4jKbWU/NfFsg7oBI3ofiYQIYeRkPSCsI9rq9otzXeWfO +PHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701996191; x=1702600991; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=8OQ4qcJBnrVu5qdEda2Vkc1e736jChzDqNzRg++7jp4=; b=jc6bgzJKM7NK55CgqqY0nW/yPJSwWOO8fBsm+Si1pGv7b1TBmRjkS/3X/ZpMjNP0cd gsBtBTlpklEv/Uzac51NkNWrRCqrbD4b9SYFGYfHG1e/PLN8McQYFmtJ3Mf6nPtTyvlB tLo+tO6wfq+5+z1fRvvyT7P8V+vwFsds0k323Gb8wBi4t5jQsbwmovzlMF79I3d/mSDF 79K3Skn9PYwR22K9/F2Pn3A+RKFqZEdSNz9ryuXrsszeVISzV85tBe7GvO921sPYPPbd znyutgYW/8oaOtKiRMqiYnDT5Ju3h+5K6n3w1UZZj1DKuUOx6DqaubjXfY+4kgXE/hNY xKuA== X-Gm-Message-State: AOJu0Yyf7fGaxCPBRmDDKdfO32n64WUHvU0ZPy3Tbro8gvB8+ZTgf6i3 b8ubhxgtMFoXMV7Ys2obcUry5EHPCivKwMjv9S4= X-Google-Smtp-Source: AGHT+IEpRm0jQ8487xc394HrqLkpMOegFa+1vLDmLWlmGaEzkTVkdOUdqPonhL6LsuUtyJKsDg8S18tMf1iCe2gOMD8= X-Received: by 2002:a5e:8e04:0:b0:7b6:ef47:7042 with SMTP id a4-20020a5e8e04000000b007b6ef477042mr2369173ion.20.1701996190674; Thu, 07 Dec 2023 16:43:10 -0800 (PST) MIME-Version: 1.0 References: <20231207192406.3809579-1-nphamcs@gmail.com> <20231207141142.307745be167d044b0eec1b42@linux-foundation.org> In-Reply-To: <20231207141142.307745be167d044b0eec1b42@linux-foundation.org> From: Nhat Pham Date: Thu, 7 Dec 2023 16:42:59 -0800 Message-ID: Subject: Re: [PATCH v6] zswap: memcontrol: implement zswap writeback disabling To: Andrew Morton Cc: tj@kernel.org, lizefan.x@bytedance.com, hannes@cmpxchg.org, cerasuolodomenico@gmail.com, yosryahmed@google.com, sjenning@redhat.com, ddstreet@ieee.org, vitaly.wool@konsulko.com, mhocko@kernel.org, roman.gushchin@linux.dev, shakeelb@google.com, muchun.song@linux.dev, hughd@google.com, corbet@lwn.net, konrad.wilk@oracle.com, senozhatsky@chromium.org, rppt@kernel.org, linux-mm@kvack.org, kernel-team@meta.com, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, david@ixit.cz, chrisl@kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 9E3B2A0028 X-Stat-Signature: drb3epo9ysfq1mk96kpdqtj33xwd8urj X-Rspam-User: X-HE-Tag: 1701996191-248343 X-HE-Meta: U2FsdGVkX19+ebcTVNcoEKgeYYofinwpn7zsneMlGw+NZ/j4hqyoHQB7qfJjBmb1ptFpAiYa1KtE8D4LyEfyjZwqOk2nvCaOe3QoqhtyW8UJiOO0RkgRNq9YgOUM6wIOoYqX1xP8A31Oq0uMxIJU5dsT0iy5/ZzUlGZzK2pDnJnL5tKZls4brE9XATyYJyiPChgEeMJqZEnjL3ZYK9adDvBr06mgbVro9xARAce/FPxxkW4MFh+GxlQVU2gEbrEA7clBoWAu3L53u9AWukxcwpdx2Og5RHc54Qp0EnGzYuoCa3iZdItzTRvh44OtR26/Naj3IbqLIX2mhrqoRvnSREE2Wi7WJnXhgsnk4jzulsWZBjGRYTU+I9sQORYku7MaQ34TMs0kuM/zHR2oWBFU1+MsCmzxi4aBPJ5iCxf0sM9ggSVLkGkCx/EBl70BS7g2FQsMhNgxQfgdIF+kd1jxxOEgBAhvMscmZHWIi79Y1sTg8xrYEYHMU6uuaVsABXtxWcvezPxJDhGLb7qgaKgApZfaecp9Q5MBKGNp/1w4aeILOWBEyIv5hA9K0orPPyiPEArG6GTMknrXuK64j84+ZwnTVlbTUiotPdgKr+2OaNW3mizqXxEvO++zU3ckXSBPuwZchCzAQ/YnX4vR3otlBbnkrogcnSnFF68uXorSs3nfDU55SngiO7gs0gkjExkHcqNuIl6BMnzPgqLud1M796v/ZVuTWmmZmX2Lum5h9xc2BnLjORQ5JUBifqyUzqJ9VOfEsWEAzJqa0U1ZRgrcWjogMmeh4/fvzulftZL/aQ2CNl+n1LapKhSIOag9JeFskMUZFbwqQLvfKlNSYS6kTHqssfQ2KkumKIc28ou+fDgQ01ZYbQp8v9Gl2tEGrJ5Qpgq0VH+wxYu8GoYdNyrPk/Oyj6XZiuayKNT32HB8tHz1xn4EkehRAXDwU87zbWV34zQXJwTOEulMAZZNFbR AlPWLvjh KAfIPGy142j/9BOl6TtGCAJXVPoMqO5LGFIgjbLsIaRu83WY/Xj06m9zYGeh9nTMcKhu470Rf2Mr9wEA+TMSwScIPxMuuKonHn0v8PnaFbytD4MIWlSaBEI6Bqk6idDqilOJO6KGRhtN6XYCtcTkJFoQsrnb53m5IYevvtXZYdjxxtpS1uhPDhwr8txpsTSqFMQwRHs4etDxjoBvP3ZOH6jAB6anS8YowlIfrXlUKZGv4OQ6B8ZgpgYZualTAQNNJaLq1Vgo37TeQbkIpteM7jLACKKoQNX45qws2Cl0x1fStQoZxrOyvaEpvQJV9puIo1p1VYpxZvB+mWrcL6cOcd83nEkQpc8/m9/hJ X-Bogosity: Ham, tests=bogofilter, spamicity=0.000190, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: > > This does seem to be getting down into the weeds. How would a user > know (or even suspect) that these things are happening to them? Perhaps > it would be helpful to tell people where to go look to determine this. When I test this feature during its development, I primarily just look at the swapin/major fault counters to see if I'm experiencing swapping IO, and when writeback is disabled, if the IO is still there. We can also poll these counters overtime and plot it/compute their rate of change. I just assumed this is usually the standard practice, and not very zswap-specific in general, so I did not specify in the zswap documentation. > > Also, it would be quite helpful of the changelog were to give us some > idea of how important this tunable is. What sort of throughput > differences might it cause and under what circumstances? For the most part, this feature is motivated by internal parties who have already established their opinions regarding swapping - the workloads that are highly sensitive to IO, and especially those who are using servers with really slow disk performance (for instance, massive but slow HDDs). For these folks, it's impossible to convince them to even entertain zswap if swapping also comes as a packaged deal. Writeback disabling is quite a useful feature in these situations - on a mixed workloads deployment, they can disable writeback for the more IO-sensitive workloads, and enable writeback for other background workloads. (Maybe we should include the paragraph above as part of the changelog?) I don't have any concrete numbers though - any numbers I can pull out are from highly artificial tasks that only serve to test the correctness aspect of the implementation. zswap.writeback disablement would of course be faster in these situations (up to 33%!!!!) - but that's basically just saying HDD is slow. Which is not very informative or surprising, so I did not include it in the changelog.