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 17055C4829A for ; Tue, 13 Feb 2024 12:57:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 767496B0092; Tue, 13 Feb 2024 07:57:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 717CF6B0093; Tue, 13 Feb 2024 07:57:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5DF0D6B0095; Tue, 13 Feb 2024 07:57:47 -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 4FA916B0092 for ; Tue, 13 Feb 2024 07:57:47 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 259F6A1644 for ; Tue, 13 Feb 2024 12:57:47 +0000 (UTC) X-FDA: 81786782574.02.D52D1C9 Received: from mail-yb1-f202.google.com (mail-yb1-f202.google.com [209.85.219.202]) by imf03.hostedemail.com (Postfix) with ESMTP id 64D0620017 for ; Tue, 13 Feb 2024 12:57:45 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=WOxjZUja; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf03.hostedemail.com: domain of 3SGfLZQoKCHkvlpovXejbadlldib.Zljifkru-jjhsXZh.lod@flex--yosryahmed.bounces.google.com designates 209.85.219.202 as permitted sender) smtp.mailfrom=3SGfLZQoKCHkvlpovXejbadlldib.Zljifkru-jjhsXZh.lod@flex--yosryahmed.bounces.google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1707829065; 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=Umi4A1gRJfLDzJlbzZAb6wHjrA4iMhaSTJrxE4a8GCU=; b=wa/BOXf2kC8LpkBBmWEgq6UQl9orbBnNlxIUicCBA4+pbXtHFk2eDWbCoLfXDV37AkdGMo PlRiEUCY2Vwp97aJPMw89II1RCLN+p+MrLHAXLMxNkPyXV1Ux9WDgT9zx4hN2fKEQPvk3A r2m9pNIh1Z8LLzzXPmEcytflCej7tkM= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=WOxjZUja; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf03.hostedemail.com: domain of 3SGfLZQoKCHkvlpovXejbadlldib.Zljifkru-jjhsXZh.lod@flex--yosryahmed.bounces.google.com designates 209.85.219.202 as permitted sender) smtp.mailfrom=3SGfLZQoKCHkvlpovXejbadlldib.Zljifkru-jjhsXZh.lod@flex--yosryahmed.bounces.google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707829065; a=rsa-sha256; cv=none; b=vwm0eqcuBABT3+v9ve/p51HyuUqMSo5pcrfijFB9rrUTNjf144YC0atlO7H6/DILuL2Aaw kA1WLm3i9mFdcvd57OgpJ3V7XDM3XiktFhmJWuUpzGssOZ/LrakIhXehyztgzWLTvHTuaO yDwl9GbetjlombfuGVD9tcOL8R/0JKA= Received: by mail-yb1-f202.google.com with SMTP id 3f1490d57ef6-dc6b26ce0bbso8445182276.1 for ; Tue, 13 Feb 2024 04:57:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1707829064; x=1708433864; darn=kvack.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=Umi4A1gRJfLDzJlbzZAb6wHjrA4iMhaSTJrxE4a8GCU=; b=WOxjZUjadvLWEplKMfyRnb1RIXThKXjRRlXNUZys8cE9fLD7WcsSQFu1wQ6igxBRGE AQmCKfj8+Ut2SOGKv/ZmolRzukgd9v3iAokMl3Aw7q3jv4lRzpvIyixpWLlIK89/fDcX gDg/lceOAhYWv9Zjsp6nYdnEX+biX22d8TSTtgZsToZ4i5VI0dIKtll5YVxACUVd4dtC ZsGOaN2sioCpgx4yTzu/+Y3kuBiTRl0WyjE0iOKzusFyVw6oB0HX37xFfuV3F7ijizb0 GV7E/9NtLbUKK7YJPAeBiIicQpp5AiWcvy/kxxKqoO3vx6EuJv5HYHZGufWKvn0iKQgF Ru1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707829064; x=1708433864; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Umi4A1gRJfLDzJlbzZAb6wHjrA4iMhaSTJrxE4a8GCU=; b=Dm3F0gEdPVZDzQaiXX9DVuCPgyHXVrZekdqnBo6/4108DIlwBNL4UPI4sBiC8XSRtl VISdv69PrXjWeKr9PEUVbAi6tAFa2ntJxk8+Eij9hyq+E1Y4ofA3J7yNUSlBMffQSdEy qvFp4SRYP4O+G34Uoo3BZofnB5PytEPM1X9hlwlEaQjJ2wD4XhuYOf+gph1oCU1WsfIN 94MFf9KcV8S0VqUU2bfKhOHlyKuqusfYnoiMCP9ItAwKgTET/Mx4Dh7hafF8IENbOtPt FJstfHF8qt9rlWiXkSSv8i4Bys2FRPZxTJgs/9PhL2PHExaViCYcvwJUUVuqYwBlk7fM 47Ww== X-Forwarded-Encrypted: i=1; AJvYcCVwdlgWLSkbx1zHB55tafnIjGFco+STsiop5yof7wV7HxwVsPatWJbBER32W7flwtLfJB3pgxiR9aPZ/FveOFesRjI= X-Gm-Message-State: AOJu0Ywn7EziS+ZKdmuRljXKO9ebwRYQs/FVE4+dMH74/031RBU7zqDS Jck3XhNXwhC8SxRbc8IyKM67SgpRdqmELS3UziZN+CxQoRyW7kTk8xkqejrcI1tjq3InqvPl14i ZIPtxDm3Ex+E/8YbOaA== X-Google-Smtp-Source: AGHT+IFMfKkTkzGgWixRu1kUKYdF5213MuinjX0UAfDLUTqb0In8qLrCEBA7jEhX6iMEAmRyWv8ldqsacZuywuXq X-Received: from yosry.c.googlers.com ([fda3:e722:ac3:cc00:20:ed76:c0a8:29b4]) (user=yosryahmed job=sendgmr) by 2002:a05:6902:1106:b0:dc7:9218:df47 with SMTP id o6-20020a056902110600b00dc79218df47mr1645904ybu.5.1707829064544; Tue, 13 Feb 2024 04:57:44 -0800 (PST) Date: Tue, 13 Feb 2024 12:57:42 +0000 In-Reply-To: <20240210-zswap-global-lru-v1-1-853473d7b0da@bytedance.com> Mime-Version: 1.0 References: <20240210-zswap-global-lru-v1-0-853473d7b0da@bytedance.com> <20240210-zswap-global-lru-v1-1-853473d7b0da@bytedance.com> Message-ID: Subject: Re: [PATCH 1/2] mm/zswap: global lru and shrinker shared by all zswap_pools From: Yosry Ahmed To: Chengming Zhou Cc: Andrew Morton , Johannes Weiner , Nhat Pham , linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="us-ascii" X-Rspamd-Queue-Id: 64D0620017 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: gujagq6b1oe7c4bsmqkkcz7d3woxp7bp X-HE-Tag: 1707829065-611735 X-HE-Meta: U2FsdGVkX1/vaTDZuzQN8GJVquDRJ6tbiERp0lBfPu5DKw/XpY1DTHWznZPm2zt/OpwF45dY28OIbWIOEZrgLZUhzG7OI6GAkoS7n352WBXIoRI3wKzxfQewWqGEMVhruhLpp/osnNbr7IA6g/MMEPw0PpT+VhAiLEYbBHzOhtWMR9ivGxbICoZzC1bjAnM3rUdHWFE/JWHZ/8bWLMGRDkUJWFTxtJG/EUCBYSJdDXc8VOjSpp28pG/buwfUc62r9++g8C28UUQp5IywmnF0I2UJZq5y8CzwqQmtbJStOfFTJTqyNHF6n3KILEl/1FDFnX2lQVI4mLp7OpFTR6VhIsWNnSFa8BXETu6nsZk+baxQEvCsmb+C1je9b+09TqVk2D/9nuT7WRTyIuB83UGzhc1bBm1Wd2sgKTpKhS3OYBcpXxBxlROo4E2QSG3iRa1iQnlg4p8KB1dnh6LUi5gbXHgMp0EH9EeoDtovdldenRdyjLE00xMgLY6CTEhjmLLLOTVCqZYruw4lVMijZDciuX086KhUQP/GB1sR4hfo37AV6Xmqzeuvz1EvRmnZd9hpt0kY1CWyvi5eZ2kJbwIkYWto/yJyNYq/nlFmBdyfoVLLfSz7FV4KHutygvInSZAX3xpuP153C0TqBUCPQEybZ2UPQ5uwJcc2fIxb6leAU+9OOJd8GrRWY4B8C/wS5PuB17mhmgVPsLHir7EFIlK2/6JZEQsaakD3fvZQy8eIy4dltCJt6saprSgSFJfl+bH+/MybMCqpSK4yGfvCW6gqvDVHfMgamME0576ctMqt4Ehib+Q3pQng5QELlUJb9OGQANrbCUckLa7pHV95OafxU0dnc5nBV6p8m6FzBzdLguEe7MIl7xLSYcHcSVeSGVIObQAm42L50JYfzrK6bi5wxCarULeWOidpIhtvU7RryqiqopTRWM6Q3N8ST2bHb0b55N1P0LC4LXL9HztGqkt Y6is1HgS Zme0CmHOWhhB8ZtNDC/YQ+drPDy5RqITjElky6SLKspJOSMa11wQ4bkVLCdT9/A3NKhiHG5rwwbRy7epLqY6jMMgfEVGhyWGgChsA0vzpZXuNBkqHT5XKCcuiKBS+v26Urs+7s/EWC5+l1XSTqfBnF5rkXGGZs+j2jVckdlA6AOuPnZug0Hg6qV1LRRaQtuSc+O4c1kOi1sDx039TY198OnFn4Z03CKuM2wndP8rS6AhfAALHsyKXKa09RDmI+EDamEFdTNqluuSt08n1A3iOEyu4aFyKuyAV37lDSVX+iqmjOr67oU5IjI1gxw/7MP7utE2xZm0y6936sefXDJq8TX0v6b11AwTaulvA0jLrbeDG8u1K9GeqyS+zZy3hLsjW6xv8KPHxWMJW3vKIVY0nJSFDDrE92H/mShsrDkN3KA+fSqz+CJhQZ71P+nAaNod5+snQTtO8h068Wk6IbVlSXh12oKcHLEMJ3fsiEBmt6yTb4Ta3m+a/wB/JvEqT29tVkmUaooj5aB7p0+wKeE3tvqgFlS0yG8vfj7t3Uypli7cSjXQ7t7ZYj73Gzh5Ew9si1ld3UUCqcWVac8kn+/ftImT20//57RKn7aDywbZV97YQt7G39HVl/yYaZrZ7SeObdj+tQe4poeVdvudttOTlVy29JW0nRutesYrGv8+cT+tFad9L+/1H2+58Dq2SV3cb5SwquaQBa8CbwiqOBXWsj82BRg13kbNCYQCy 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 Sun, Feb 11, 2024 at 01:57:04PM +0000, Chengming Zhou wrote: > Dynamic zswap_pool creation may create/reuse to have multiple > zswap_pools in a list, only the first will be current used. > > Each zswap_pool has its own lru and shrinker, which is not > necessary and has its problem: > > 1. When memory has pressure, all shrinker of zswap_pools will > try to shrink its own lru, there is no order between them. > > 2. When zswap limit hit, only the last zswap_pool's shrink_work > will try to shrink its lru, which is inefficient. > > Anyway, having a global lru and shrinker shared by all zswap_pools > is better and efficient. It is also a great simplification. > > Signed-off-by: Chengming Zhou > --- > mm/zswap.c | 153 ++++++++++++++++++++++--------------------------------------- > 1 file changed, 55 insertions(+), 98 deletions(-) > > diff --git a/mm/zswap.c b/mm/zswap.c > index 62fe307521c9..7668db8c10e3 100644 > --- a/mm/zswap.c > +++ b/mm/zswap.c > @@ -176,14 +176,17 @@ struct zswap_pool { > struct kref kref; > struct list_head list; > struct work_struct release_work; > - struct work_struct shrink_work; > struct hlist_node node; > char tfm_name[CRYPTO_MAX_ALG_NAME]; > +}; > + > +struct { static? > struct list_lru list_lru; > - struct mem_cgroup *next_shrink; > - struct shrinker *shrinker; Just curious, any reason to change the relative ordering of members here? It produces a couple more lines of diff :) > atomic_t nr_stored; > -}; > + struct shrinker *shrinker; > + struct work_struct shrink_work; > + struct mem_cgroup *next_shrink; > +} zswap; > > /* > * struct zswap_entry > @@ -301,9 +304,6 @@ static void zswap_update_total_size(void) > * pool functions > **********************************/ > > -static void zswap_alloc_shrinker(struct zswap_pool *pool); > -static void shrink_worker(struct work_struct *w); > - > static struct zswap_pool *zswap_pool_create(char *type, char *compressor) > { > int i; > @@ -353,30 +353,16 @@ static struct zswap_pool *zswap_pool_create(char *type, char *compressor) > if (ret) > goto error; > > - zswap_alloc_shrinker(pool); > - if (!pool->shrinker) > - goto error; > - > - pr_debug("using %s compressor\n", pool->tfm_name); > - Why are we removing this debug print? > /* being the current pool takes 1 ref; this func expects the > * caller to always add the new pool as the current pool > */ > kref_init(&pool->kref); > INIT_LIST_HEAD(&pool->list); > - if (list_lru_init_memcg(&pool->list_lru, pool->shrinker)) > - goto lru_fail; > - shrinker_register(pool->shrinker); > - INIT_WORK(&pool->shrink_work, shrink_worker); > - atomic_set(&pool->nr_stored, 0); > > zswap_pool_debug("created", pool); > > return pool; > > -lru_fail: > - list_lru_destroy(&pool->list_lru); > - shrinker_free(pool->shrinker); > error: > if (pool->acomp_ctx) > free_percpu(pool->acomp_ctx); [..] > @@ -816,14 +777,10 @@ void zswap_folio_swapin(struct folio *folio) > > void zswap_memcg_offline_cleanup(struct mem_cgroup *memcg) > { > - struct zswap_pool *pool; > - > - /* lock out zswap pools list modification */ > + /* lock out zswap shrinker walking memcg tree */ > spin_lock(&zswap_pools_lock); > - list_for_each_entry(pool, &zswap_pools, list) { > - if (pool->next_shrink == memcg) > - pool->next_shrink = mem_cgroup_iter(NULL, pool->next_shrink, NULL); > - } > + if (zswap.next_shrink == memcg) > + zswap.next_shrink = mem_cgroup_iter(NULL, zswap.next_shrink, NULL); Now that next_shrink has nothing to do with zswap pools, it feels weird that we are using zswap_pools_lock for its synchronization. Does it make sense to have a separate lock for it just for semantic purposes? > spin_unlock(&zswap_pools_lock); > } > [..] > @@ -1328,7 +1284,6 @@ static unsigned long zswap_shrinker_scan(struct shrinker *shrinker, > static unsigned long zswap_shrinker_count(struct shrinker *shrinker, > struct shrink_control *sc) > { > - struct zswap_pool *pool = shrinker->private_data; > struct mem_cgroup *memcg = sc->memcg; > struct lruvec *lruvec = mem_cgroup_lruvec(memcg, NODE_DATA(sc->nid)); > unsigned long nr_backing, nr_stored, nr_freeable, nr_protected; > @@ -1343,7 +1298,7 @@ static unsigned long zswap_shrinker_count(struct shrinker *shrinker, > #else > /* use pool stats instead of memcg stats */ > nr_backing = get_zswap_pool_size(pool) >> PAGE_SHIFT; "pool" is still being used here. > - nr_stored = atomic_read(&pool->nr_stored); > + nr_stored = atomic_read(&zswap.nr_stored); > #endif > > if (!nr_stored) [..] > @@ -1804,6 +1749,21 @@ static int zswap_setup(void) > if (ret) > goto hp_fail; > > + shrink_wq = alloc_workqueue("zswap-shrink", > + WQ_UNBOUND|WQ_MEM_RECLAIM, 1); > + if (!shrink_wq) > + goto hp_fail; I think we need a new label here to call cpuhp_remove_multi_state(), but apparently this is missing from the current code for some reason. > + > + zswap.shrinker = zswap_alloc_shrinker(); > + if (!zswap.shrinker) > + goto shrinker_fail; > + if (list_lru_init_memcg(&zswap.list_lru, zswap.shrinker)) > + goto lru_fail; > + shrinker_register(zswap.shrinker); > + > + INIT_WORK(&zswap.shrink_work, shrink_worker); > + atomic_set(&zswap.nr_stored, 0); > + > pool = __zswap_pool_create_fallback(); > if (pool) { > pr_info("loaded using pool %s/%s\n", pool->tfm_name, > @@ -1815,19 +1775,16 @@ static int zswap_setup(void) > zswap_enabled = false; > } > > - shrink_wq = alloc_workqueue("zswap-shrink", > - WQ_UNBOUND|WQ_MEM_RECLAIM, 1); > - if (!shrink_wq) > - goto fallback_fail; > - > if (zswap_debugfs_init()) > pr_warn("debugfs initialization failed\n"); > zswap_init_state = ZSWAP_INIT_SUCCEED; > return 0; > > -fallback_fail: > - if (pool) > - zswap_pool_destroy(pool); > +lru_fail: > + list_lru_destroy(&zswap.list_lru); Do we need to call list_lru_destroy() here? I know it is currently being called if list_lru_init_memcg() fails, but I fail to understand why. It seems like list_lru_destroy() will do nothing anyway. > + shrinker_free(zswap.shrinker); > +shrinker_fail: > + destroy_workqueue(shrink_wq); > hp_fail: > kmem_cache_destroy(zswap_entry_cache); > cache_fail: > > -- > b4 0.10.1