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 0D25EC4332F for ; Sat, 11 Nov 2023 00:10:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 286418D00FA; Fri, 10 Nov 2023 19:10:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 236658D0005; Fri, 10 Nov 2023 19:10:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0FEBF8D00FA; Fri, 10 Nov 2023 19:10:29 -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 03D278D0005 for ; Fri, 10 Nov 2023 19:10:29 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id CD9E7801DB for ; Sat, 11 Nov 2023 00:10:28 +0000 (UTC) X-FDA: 81443741736.23.1AD46C8 Received: from mail-io1-f50.google.com (mail-io1-f50.google.com [209.85.166.50]) by imf26.hostedemail.com (Postfix) with ESMTP id 0AE1F14001D for ; Sat, 11 Nov 2023 00:10:26 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=EXE9ng08; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf26.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.166.50 as permitted sender) smtp.mailfrom=nphamcs@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1699661427; 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=cxFVU/O++xjmTUwRIyuxUTtJP9CCcilQCzHndj7FEYs=; b=oXRMYA2o497Pe0/jBiFKbV6zCt/ueMqtm+U7MUdkweAgrbw3FpsT7jhsC1rElFSi5ytw/z CYj/AaMSs7WYj979PS10xcAf7xRfGoV82hQdtGZR6mCJfwt2rLLaw9Yu5w06ihqniBXy/r /oR7+oU5M/9xfNYHDY1OJwTRB8ZI9zU= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=EXE9ng08; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf26.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.166.50 as permitted sender) smtp.mailfrom=nphamcs@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1699661427; a=rsa-sha256; cv=none; b=KtxjIzi8/HyS6ieCCKl+hTmW97GHokM+TU5GMP5N/x7ShjoAnjVArCiCFrR0FNbFSedLhY 2fVxeOy1iW/Pzr9ccIyQ4zpWQtkxGKTLY7jvsjkVpJVhAihEjAmDqnYAeHcZ8YY3gGm5gi v3SUFCnQIV/7BO03JQ6z/yrLHjAvwOk= Received: by mail-io1-f50.google.com with SMTP id ca18e2360f4ac-7a93b7fedc8so101134539f.1 for ; Fri, 10 Nov 2023 16:10:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699661426; x=1700266226; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=cxFVU/O++xjmTUwRIyuxUTtJP9CCcilQCzHndj7FEYs=; b=EXE9ng08mdRSSyhU/VvCWLwTuuIj5Ift2SpuiCSjqa2sLkflKfA3TY7VBw5echl82K b7/o81eRYMiwerNME7CD1LvDYYfa365t3Xbj0Toi0qVq8ojXr6fPSTISRArL8n+QUn+1 2usts65DM6U8K8EpS5rxYTKlFfvRO6gASa+ewtybqrR3eb81w5Rpk7eDWUQBqUVXOOqo gVP6+C7y1M5Dv4y4v75vST3tKgysf6KdeLoQHrL7ngp/KR8/uE53dbRLiJh1jJ64cpVU zxXcuoLyLMbd80svt9jVMKkVM7oK0f7BjtUJxFJUGJ1repW14NghUlKkrpNyx3FhYo3g 45Uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699661426; x=1700266226; h=content-transfer-encoding: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=cxFVU/O++xjmTUwRIyuxUTtJP9CCcilQCzHndj7FEYs=; b=Kawceq+YnkkIzpysfIt3+Z8L1PN6M5JxVpWiop0CaoUTAWsFk5j8DEHR6Jyj2SbG0K D7EU6zf1Ca7Ja/rCV9zVea66d6i2K2SHnTlFrObX0KOHgvCJyyyugJRg1RLnQuqyc195 ZF/B+QMxevu5rGBvqA0Ob97YM6BVjZd/oN/ZK1/BTzrSNo90k7bWI6dsgWMPps+7p3Fq 6YvjOJAj+ahkxKGa3K7m/4UKUnGZMeYLmjURwjXgXdbF70o7v2YcpxHfA4e7v/FMKNGB foqb2PDCRlvsZcliKS9KDTxQSdmSOpywo92jWVJAwz7hMafWOH2lMFE9Gbqu0Sj/xzj5 aHrg== X-Gm-Message-State: AOJu0YzTcsCRrR1S4SAeqLNbkb0ksxEiVAamxVbmNCuBlHQ/sn7JlYU4 iN1mT71ncUCMKkhCU5TarXmLiyxcgNpI7h33fuo= X-Google-Smtp-Source: AGHT+IE5zVX9XFLdvU0U9v6tHC+jPR/bJBfCK2y0DtpDCDOycmbMLl6zIsI6TPPAuAWcAbSWDbmTNSb2EibQvEgEAVU= X-Received: by 2002:a5d:9506:0:b0:798:d82b:7b02 with SMTP id d6-20020a5d9506000000b00798d82b7b02mr939096iom.4.1699661426127; Fri, 10 Nov 2023 16:10:26 -0800 (PST) MIME-Version: 1.0 References: <20231106231158.380730-1-nphamcs@gmail.com> In-Reply-To: From: Nhat Pham Date: Fri, 10 Nov 2023 16:10:14 -0800 Message-ID: Subject: Re: [PATCH v4] zswap: memcontrol: implement zswap writeback disabling To: Chris Li Cc: Andrew Morton , tj@kernel.org, lizefan.x@bytedance.com, Johannes Weiner , Domenico Cerasuolo , Yosry Ahmed , Seth Jennings , Dan Streetman , Vitaly Wool , mhocko@kernel.org, roman.gushchin@linux.dev, Shakeel Butt , muchun.song@linux.dev, Hugh Dickins , corbet@lwn.net, Konrad Rzeszutek Wilk , senozhatsky@chromium.org, rppt@kernel.org, linux-mm , kernel-team@meta.com, LKML , linux-doc@vger.kernel.org, david@ixit.cz Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 0AE1F14001D X-Stat-Signature: ibrcwogx81gzafd9k4x5355bo8gh8hp9 X-HE-Tag: 1699661426-581672 X-HE-Meta: U2FsdGVkX1/cnA/X9NISJnroF1127AWfWhkYL5dpT/+CfAccNvsUIrsZbTCNj6h4862Zih6VsZBAxutizYX0CvNROTcYwksvmWcETZBlpa/XTc+Ga3z1z5Grkf/0JjPU+u42vLBpyt4axdZI/HnHhDVag17oGtUpZNcs5O/cGYzoA1MA+m9muvjcKRb7kMxY804BrJdVycLM6Nf5w4UiO1uWQJxPxm/iarfbYG5arB3+OuIZUpjWIxILgiPupFnjL+pQdDh5tw04mX1ASpXWkiSBH0vB/s1HGdRD2ndsRROOdbjxSbkIrfaNPsAd92J8EhwkqTGFdvnG8MUkDOp9AsmvC+ExRotcmEYzR8MzUABSgRHr/6MxiQz0SI2STr6n1Pi8RBC9DXbs2SyX1aP+do4+11OgrpPbHlvbqdncNs/pEO8DCPst6QZmN/gAeEgeUqk6LmqlAYOblV0q8w0pe1+pdKGKeqUEyKwrBq5c8FiMOks0SkcvdP5Ai5GerIadKCZROhlQoCmecPvAbejt1WspaKO4MND2hW/eIPeBvIuwfCJRXgv4vfui4dMT8wp9hJYjD+jhz4/yy1hKAMfjK6Dyy4B39rJHBg+0MAk56yJmW0nJRmurQC8jEXVNIPDTjEwDxoFT0j5waM5SqliW7aLBhi438vp+AIRuehdtaOnG+yWvJ01rWB8J+0q+0Ng+8hjXUKpJmp1Pp6GxBm8JzVXv48OJ5JTenEfttFywWD9dLlJuk1ywJ2uukTEErpHUOHJ0ch+MKIbc8YcAtmr+4ZfDgjvFdAscs17YMGUQXi7tdevhoMNnQnKCQLUvQRak7xflsd3+rIPZQE4NaSpeb3Qm0gkgEAkcM+cXBNtgkstye3hkhz90rXxd1+UKcj9iGIxvR8l4Zf5hZba6f2ZJPQSlz0YARoPomCpTtSjlyJVDJEGquxYhIBONZmXuzANWFZQjvA+Pu70QDls6str a1bRaniD f1hrndcVwXQ71Jgt4P+qpWH4qMtY+hhpejabhe9RcvFi/aZI57oL1pZJZy4JQsFv7PB43Ihq2o8rqMaORbY6hgAVfhKypzDesilbjkMt+vxQtzOz0OzjTiA7jpBR5IqRUEyYASCt4wp+C5vkDoo4Uk70wGByGLfsBBHd9jIxNNP4kc7+KrkW8ZgT8cpPohtzvvJZaNexKGGfzD+EMO9Obtxk/95NIB0OY/sb1/63NNHEZywYLQdhMae/D6ftFr9iseDMEzBppXHMajQYbo1Xal+iKOF/7YmRN863eAzEI+moE1+m6XTr8B+bAGDzliYg8MCyZMnLicoBGCf1Qv2atsKhT7RO5vExq+Rj9Zlo9MKEL4LbDAiPiQnOtktCpgKgVGX+482FYvlHMMHXnwuuB8UQYJ8FgXp2BWcVnolf9tWyrIefX6R8CCacNrg== 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 Fri, Nov 10, 2023 at 3:10=E2=80=AFPM Chris Li wrote: > > Hi Nhat, > > Acked-by: Chris Li Thanks, Chris! > > On Mon, Nov 6, 2023 at 3:12=E2=80=AFPM Nhat Pham wrot= e: > --- a/include/linux/memcontrol.h > +++ b/include/linux/memcontrol.h > @@ -219,6 +219,12 @@ struct mem_cgroup { > > #if defined(CONFIG_MEMCG_KMEM) && defined(CONFIG_ZSWAP) > unsigned long zswap_max; > + > + /* > + * Prevent pages from this memcg from being written back from zsw= ap to > + * swap, and from being swapped out on zswap store failures. > + */ > + bool zswap_writeback; > #endif > > I notice the bool is between two integers. > mem_cgroup structure has a few bool sprinkle in different locations. > Arrange them together might save a few padding bytes. We can also > consider using bit fields. > It is a very minor point, the condition also exists before your change. This sounds like an optimization worthy of its own patch. Two random thoughts however: a) Can this be done at the compiler level? I believe you can reduce the padding required by sorting the fields of a struct by its size, correct= ? That sounds like a job that a compiler should do for us... b) Re: the bitfield idea, some of the fields are CONFIG-dependent (well like this one). Might be a bit hairier to do it... > > > #endif /* _LINUX_ZSWAP_H */ > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > > index e43b5aba8efc..9cb3ea912cbe 100644 > > --- a/mm/memcontrol.c > > +++ b/mm/memcontrol.c > > @@ -5545,6 +5545,11 @@ mem_cgroup_css_alloc(struct cgroup_subsys_state = *parent_css) > > WRITE_ONCE(memcg->soft_limit, PAGE_COUNTER_MAX); > > #if defined(CONFIG_MEMCG_KMEM) && defined(CONFIG_ZSWAP) > > memcg->zswap_max =3D PAGE_COUNTER_MAX; > > + > > + if (parent) > > + WRITE_ONCE(memcg->zswap_writeback, READ_ONCE(parent->zs= wap_writeback)); > > + else > > + WRITE_ONCE(memcg->zswap_writeback, true); > > You can combine this two WRITE_ONCE to one > > bool writeback =3D !parent || READ_ONCE(parent->zswap_writeback); > WRITE_ONCE(memcg->zswap_writeback, writeback); > Yeah I originally did something similar, but then decided to do the if-else instead. Honest no strong preference here - just felt that the if-else was cleaner at that moment. > Chris