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 53D72CEBF61 for ; Thu, 26 Sep 2024 23:40:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 92C496B009C; Thu, 26 Sep 2024 19:40:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8DC9D6B009E; Thu, 26 Sep 2024 19:40:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 755706B009F; Thu, 26 Sep 2024 19:40:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 550EC6B009C for ; Thu, 26 Sep 2024 19:40:13 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 0714F1A06CB for ; Thu, 26 Sep 2024 23:40:13 +0000 (UTC) X-FDA: 82608510306.28.1BC0AE7 Received: from mail-ej1-f48.google.com (mail-ej1-f48.google.com [209.85.218.48]) by imf22.hostedemail.com (Postfix) with ESMTP id 01C10C000C for ; Thu, 26 Sep 2024 23:40:10 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=intelfx.name header.s=google header.b=MfswLkJc; dmarc=none; spf=pass (imf22.hostedemail.com: domain of intelfx@intelfx.name designates 209.85.218.48 as permitted sender) smtp.mailfrom=intelfx@intelfx.name ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727393994; a=rsa-sha256; cv=none; b=HDmVGRCfgZmFOoaGlE+UM5hqX262mKjTaa7AoyVrw46Y+fIQnsaXYcQsBmGDiafu9aYyb2 3OPtR6PMu0CN0BZ0F48603F1JFn5O7BUFWySI2bKCpJBaZhbLDQ9rfHyAB6FYOrrvQcvtW ihiNA+lep8UGo7RhoC6/fLlihYSyEtQ= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=intelfx.name header.s=google header.b=MfswLkJc; dmarc=none; spf=pass (imf22.hostedemail.com: domain of intelfx@intelfx.name designates 209.85.218.48 as permitted sender) smtp.mailfrom=intelfx@intelfx.name ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727393994; 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=uKpTAzqoyySlR+8oqQyPqaB39JLjizvNxi99XSP5i98=; b=zl0wNllS2vramoNKHHqaXVjT6rOP22XkWXGoHGfyYLXOb8DLgAuE1zU7cm8X7sXoFpRAxf DoxCxhqIC6uwR1NopDDhYNpe2c6rae09dQ6UIgju+LqJ4Z2qgeeP9HCua2Zdb8cBLLi9IZ fJL089i3O6TJb1+ODvGRVSjEZLp9YbA= Received: by mail-ej1-f48.google.com with SMTP id a640c23a62f3a-a8d0d0aea3cso207902966b.3 for ; Thu, 26 Sep 2024 16:40:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intelfx.name; s=google; t=1727394009; x=1727998809; darn=kvack.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=uKpTAzqoyySlR+8oqQyPqaB39JLjizvNxi99XSP5i98=; b=MfswLkJcT+VnPrVA/UyqcBcEnl3syUM1nqzUPrU8GQ2C6U1qlDvR1LjPqweDfPTu9u pV5L8tFI/9uembk8gGm2wuIsGwiwsoW8cvJ3sXCv2B/ufcwBKkPI1J87/Xsdjbq1zt1P 24XmPGqNeyT8+0rqhTKww0SVximWpw/unhVTk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727394009; x=1727998809; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=uKpTAzqoyySlR+8oqQyPqaB39JLjizvNxi99XSP5i98=; b=foMgeU8uaOeBEee9QXaw9d5wDJYKrOi/JhCPRAOEc/0TKXgYwz6oYF4ckLQXnynb4c OgOmzfuV1dxOnGI2dFUCRXn7t+RMqL8V0aL49zvGisySmkzow5NS7WLgrKpFtbE5uIYl +jsh+ezFVXaCWcBBJTgxOzcEujG/bQ6RNIqeT2uwLMyhxcsGuA0qUpqc3S01hnU3ERhg TSpRycqL6qrEUJAWdXOr+Cgdeyxqb/KovpQBqme5OkGEOqLd1uv8MkVx50hmzLkNrhs9 hsLrNqxQ8TDu9IQ53UXeX6T+XRUf1xDplWhtya57QIOra20W5ipQmy77h3TEJ/ZAe8D0 Fe2g== X-Forwarded-Encrypted: i=1; AJvYcCWjI+noX5poF2WqNV4zY8cK0J/slhzade5n75sRqBiTOjjcw0iC5uLxCEqQu7jefJks4h78Z/yXTQ==@kvack.org X-Gm-Message-State: AOJu0YxCyo7w9bLNRFRbq4VAtwT8UddSX9PauIyUtWQEJ+XDk/tk5pDl bAifoNep1zsTAU+I+3t0eLhKr6UJRSH6Qr4/F+mySSz8tAWTSJgABrB/p0aFATQ= X-Google-Smtp-Source: AGHT+IGk3lENN9qHrkJbZyp06+cpIkHb4ayVeIlhXVUADB4zcIETe8YE9A2AKIcrQu83XuXRnfdFEw== X-Received: by 2002:a17:907:3f9e:b0:a7a:b070:92c6 with SMTP id a640c23a62f3a-a93c4a880acmr85163766b.50.1727394009153; Thu, 26 Sep 2024 16:40:09 -0700 (PDT) Received: from able.exile.i.intelfx.name ([188.129.244.140]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a93c27ecd10sm51403266b.96.2024.09.26.16.40.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Sep 2024 16:40:07 -0700 (PDT) Message-ID: Subject: Re: [PATCH] zswap: improve memory.zswap.writeback inheritance From: Ivan Shapovalov To: Nhat Pham Cc: linux-kernel@vger.kernel.org, Mike Yuan , Tejun Heo , Zefan Li , Johannes Weiner , Michal =?ISO-8859-1?Q?Koutn=FD?= , Jonathan Corbet , Yosry Ahmed , Chengming Zhou , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , Andrew Morton , Chris Li , cgroups@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org Date: Fri, 27 Sep 2024 01:40:04 +0200 In-Reply-To: References: <20240926225531.700742-1-intelfx@intelfx.name> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.54.0 MIME-Version: 1.0 X-Rspam-User: X-Stat-Signature: m9gt7zhc9s9zywdyzgtmdztjroa6cewp X-Rspamd-Queue-Id: 01C10C000C X-Rspamd-Server: rspam02 X-HE-Tag: 1727394010-101597 X-HE-Meta: U2FsdGVkX1/19SZFFx7OMlObu7EeaWfR6CgEzvUmgzFkwHLzKwzoDuJ1La/ZH6l9EvPBZIveVfwfYX0Ujxwv4Uya2x4zy+7JE5Oi7d6vn55+z7VAAOg9JeWxXEBN19SeMNQVNEGtEIufhe91doX3e+OegJTIdc1FcaJW2R7VG1FHvCsO1k0VovKCkKa+dWf4f1U+tB2EQlCU4cKquJt9uElf9452isW9PRg/V94he30tSKKtLM5beADY63lP7ILM2iijwfetk2rdXuVlY8vSQgocIt4MzbN8R36jlsABz+Nk85ymNxm/4zdfN6InyK4WATqi0PutIuNDGvJsStWA6X6pWJtiGk9W6qRPd0Ee41LjQm94/DrqFPKWkCPIwLqHhmN2xdNhtxV4ITGLS+aBWPbXlUkjc+AJCF5ALlPZjMtfLjgskihzhoHI0mF/4vxDlccEsC4x6/7LqF0I6tFQSNantNb/2bopSe5cD7B18FvsHEVCNHqCm3ot1CMmgQwN6Us5eo8U7b/ZzwB8hx8/PoW3AEIMCD/bCpTY5wvUKIoHKy2pg30461mnLDMP9rNHgyHXBuD8PHrbRDnh2SbVL7AsagcGsXywlXRNORh5wJWQ/YxZbKaW7D64GANEoUm+QG9qpAYidCQD8hphVPet1r+L8tpYuFHTyNDetvjtWVMFM0Bn4K4jgMdzS4M+gG29kHqyutgJjNO6Drs0tYbM7XUjgwRURE8OTR9qVEhMyd07nF+Pmn4vKqEir+4V40BBdnzaBezNSOGbyTsA96ue+4S3WRZxFHQf23JbgkMAQinAYwkV6KusMPN5MlLIVNtMVZ2yqkpzVFowFzLU85cp7ZZvLfjGevh/s6OzmIMHqY6SmsBr7blVGgYQJIOEHrrFIaxLojP3ZCHHbRFhcWtxBiGdgYfL5W0btunSAsF2F/SvSYx/DI/IiFL4A2OArbOwcqCx5HUWIL256S8Q1ZQ PTSkpPn8 D3uuAmymeO3Em+9DwHsf8fH//Hf2JagD8xnInP62np63lqN+vun+7BPychu3jZI11MGy2W/Z87sMKIiaonv4nJKrWwDg96l75WwpI0UK6rehIZzwybemWigOLrtqlBGVzsuMG3p64saQxkSRI8B3sEFPUUo360VU+JSpVzoWRgMUjOVCalK88h41UZvWydqrb3TTTkclRvpAx/Iece3LOkxn4UlW9RjR5pc/aQbwBqo+hoDkGIRQcUL3q/6hlf6VRxC5wPH5f77CRoCRnMwxWqsLgTu49r6gZzlz4rfOPv4eFrgEz5VxqQLjLSmemfc1IZb67djeYzjeCMKSyAcRlDKRhJjPhb9ZllqlQ 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-09-26 at 16:12 -0700, Nhat Pham wrote: > On Thu, Sep 26, 2024 at 3:55=E2=80=AFPM Ivan Shapovalov wrote: > >=20 > > Improve the inheritance behavior of the `memory.zswap.writeback` cgroup > > attribute introduced during the 6.11 cycle. Specifically, in 6.11 we > > walk the parent cgroups until we find a _disabled_ writeback, which doe= s > > not allow the user to selectively enable zswap writeback while having i= t > > disabled by default. >=20 > Is there an actual need for this? This is a theoretical use case I > thought of (and raised), but I don't think anybody actually wants > this...? This is of course anecdata, but yes, it does solve a real use-case that I'm having right now, as well as a bunch of my colleagues who recently complained to me (in private) about pretty much the same use-case. The use-case is following: it turns out that it could be beneficial for desktop systems to run with a pretty high swappiness and zswap writeback globally disabled, to nudge the system to compress cold pages but not actually write them back to the disk (which would happen pretty aggressively if it was not disabled) to reduce I/O and latencies. However, under this setup it is sometimes needed to re-enable zswap writeback for specific memory-heavy applications that allocate a lot of cold pages, to "allow" the kernel to actually swap those programs out. >=20 > Besides, most people who want this can just: >=20 > 1. Enable zswap writeback on root cgroup (and all non-leaf cgroups). >=20 > 2. Disable zswap writeback on leaf cgroups on creation by default. >=20 > 3. Selectively enable zswap writeback for the leaf cgroups. >=20 > All of this is quite doable in userspace. It's not even _that_ racy - > just do this before adding tasks etc. to the cgroup? Well, yes, it is technically doable from userspace, just like it was technically doable prior to commit e39925734909 to have userspace explicitly control the entire hierarchy of writeback settings. However it _is_ pretty painful, and the flow you described would essentially negate any benefits of that patch (it would require userspace to, once again, manage the entire hierarchy explicitly without any help from the kernel). IOWs, per the above commit I concluded that reducing pain levels for userspace implementations was an acceptable design goal :-) Thanks, --=20 Ivan Shapovalov / intelfx /