From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ot1-f53.google.com (mail-ot1-f53.google.com [209.85.210.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7F9E2330B11 for ; Wed, 4 Mar 2026 15:11:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772637086; cv=none; b=i2o91OwXlivbF0tJp7mZez3QBzDiYidWS4mLRDy4G2YH8HJooBQldSvqIUWaspU2JwhLHU8UpAThSqpFU14FaIMj5BrbIbYoXv30JbKATvHJqP6dDwrO4TkTqncZh0/Yk8dvhBHvvbhblA4+tImdDaKjYuXcyY5libe3jJCevM8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772637086; c=relaxed/simple; bh=V0oPLGegAhTc4L7WHvwIBZ0RDMLRRcbNO/H/6P29W7A=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ajy1lloShaQ9YGYVC7BVoKJEGD9dmKn42yK/hJ7gVSJ4I4Nbv1kIPYvPzNhNu+FLcCkMs5krdlIzu8brBD6C5v9N8aLoS+VM9KKXIJSc2HCSUvu7mTgIEbZtEDzcpqrz4m6lDoCGfMGZpXyCZJivv6Q3UzNzIb72Ri+jRc/IeHg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Lc2pIY/9; arc=none smtp.client-ip=209.85.210.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Lc2pIY/9" Received: by mail-ot1-f53.google.com with SMTP id 46e09a7af769-7d4b9c839b1so3617984a34.1 for ; Wed, 04 Mar 2026 07:11:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772637082; x=1773241882; darn=vger.kernel.org; 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=QoKsT5JRqIpY8UANHFptI+GVlx4Jt8dOkJklplEKYw4=; b=Lc2pIY/9RTwoj50ViRSox8PwOi5H+ZeP6ZsXlXNTZSyjLum+lwcxYRWTzoOPlyiJeE Cdn2MBEiMuQZSduXp5Q9cIH8OcogiF+8HGeXP4dSoO3p5epk7OyWhKelcSbEr87Si1hN kIidGE0jc7vZrz6Rm7QMk2vh8tljdf70snr/WQM8P9+lcqgvpRmgEJ/84wiLs10ewUF7 yl0lWk5x/1AUPE65HVks1XFm/b8wcXEYPb49yyuXuJccuCbhUZO8ccvsOhiskAea/kUS KN9gszAXpKsfJeSg9gh8/tEZLZcYX+Xfl5GIig5nnwzKddOeRefR8EiMpWatruLGDC7Y g9AQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772637082; x=1773241882; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=QoKsT5JRqIpY8UANHFptI+GVlx4Jt8dOkJklplEKYw4=; b=Yl2lkGDcU3agRb/Zx8ysRjDM6FQq8xJnHak84PO3LlJgfOojgb9L4IaZiDFIMClM6M aUaHfsa0CzUtINh3HWwxvGDo7Ie3K+K6qNTy39q5av0Ev8aKaSgTgljOuyMFT4ywtdu4 aJvtD2iuIHJE95y4U3lQHgCV56QAAHTFp+jko5CCsUkWs+JNW6TM/AC5+WuXmK7vr7qO Mz7u9Tpu89qOF/rYegpq72O5SMYO71jHE8Ud2jBBIsnktTYZdBgLEaaj/ZeGM2mGYd7t eMGQdVzIoG+hZSkNUrF8fDlJsjJ0uMaLSkI+0LSxyVWB+4jZkdKceBDp0xO92Om2ryNm M3jA== X-Forwarded-Encrypted: i=1; AJvYcCU8ccw2zCYVmhHuW8coASubFlsjEEYgYRXt5dbXiIGshepLDiwQaAsMsfOLvdAu5g0a2Ww0QQKIpXkYb2Y=@vger.kernel.org X-Gm-Message-State: AOJu0YxPfCFpLCvdA3YoHWNUsTmAYxAVJztdiO9J7RnbnkCQTqo53Ezf J6DdxJHzp69ieJ5I0GS2U9GwusvKfu3SX3+FmXAkHYR3wgK6FxNZbndV X-Gm-Gg: ATEYQzw5ek4hwXhbB6NeX4IgdJ5iafqKpBYJJW6vwXPvS6YhWFeByqmVXeFu/TNJSJ8 X+aZSvNb/Lzge/JDi3HHGHnEdgD0XFPeR6O5dOcN42Hll+XgWhAC8kYO+QTngzNgbvJIl20umkB /0LuiBXIa+fJtFZ6vD3y744r1tJYjbNJpJERG/rV60YhY+Y1cK16z32BrNZskNHTpHBQ02i3d/V XonCNoHwKUcoZE5+FY+C09jVBegSgV4USpam8LTeBL7F/b8fM6evEmP1/FpfB2nsi6W6/n5CIBl VcY1NIjqN2xLGBEszT2THz+ccS1MFYC1w3RvTqzW1yN42fU739w3hv1DCdUxZIwZoWz5tqCEdij eFEOL0ILjiRvKyWBoebJi7Z3zW7l+X8Y6Ghz+XVVxYtZz5ZCFlOab9AYtLmQBuGfO3Lz2e+YofT TaCsxtYOFih04HCVIOeY69ug== X-Received: by 2002:a05:6830:388c:b0:7d1:90d6:1f5c with SMTP id 46e09a7af769-7d6c7f4bc25mr1088903a34.4.1772637082089; Wed, 04 Mar 2026 07:11:22 -0800 (PST) Received: from localhost ([2a03:2880:10ff:53::]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-7d5866701cdsm15564292a34.29.2026.03.04.07.11.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Mar 2026 07:11:21 -0800 (PST) From: Joshua Hahn To: Yosry Ahmed Cc: Minchan Kim , Sergey Senozhatsky , Johannes Weiner , Yosry Ahmed , Nhat Pham , Nhat Pham , Chengming Zhou , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , Andrew Morton , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@meta.com Subject: Re: [PATCH 6/8] mm/zsmalloc, zswap: Handle objcg charging and lifetime in zsmalloc Date: Wed, 4 Mar 2026 07:11:19 -0800 Message-ID: <20260304151120.3512645-1-joshua.hahnjy@gmail.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On Tue, 3 Mar 2026 15:53:31 -0800 Yosry Ahmed wrote: > > diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c > > index 067215a6ddcc..88c7cd399261 100644 > > --- a/mm/zsmalloc.c > > +++ b/mm/zsmalloc.c > > @@ -963,6 +963,44 @@ static bool alloc_zspage_objcgs(struct size_class *class, gfp_t gfp, > > return true; > > } > > > > +static void zs_charge_objcg(struct zpdesc *zpdesc, struct obj_cgroup *objcg, > > + int size, unsigned long offset) > > +{ > > + struct mem_cgroup *memcg; > > + > > + if (!cgroup_subsys_on_dfl(memory_cgrp_subsys)) > > + return; > > + > > + VM_WARN_ON_ONCE(!(current->flags & PF_MEMALLOC)); > > + > > + /* PF_MEMALLOC context, charging must succeed */ > > + if (obj_cgroup_charge(objcg, GFP_KERNEL, size)) > > + VM_WARN_ON_ONCE(1); > > + > > + rcu_read_lock(); > > + memcg = obj_cgroup_memcg(objcg); > > + mod_memcg_state(memcg, MEMCG_ZSWAP_B, size); > > + mod_memcg_state(memcg, MEMCG_ZSWAPPED, 1); Hello Yosry, I hope you are doing well! Thank you for your feedback : -) > Zsmalloc should not be updating zswap stats (e.g. in case zram starts > supporting memcg charging). How about moving the stat updates to > zswap? Yeah... I think this was also a big point of concern for me. While reading the code, I was really amazed by how clean the logical divide between zsmalloc and zswap / zram were, and I wanted to preserve it as much as possible. There are a few problems, though. Probably the biggest is that migration of zpdescs and compressed objects within them are invisible to zswap. Of course, this is by design, but this leads to two problems. zswap's ignorance of compressed objects' movements across physical nodes makes it impossible to accurately charge and uncharge from the correct memcg-lruvec. Conversely, zsmalloc's ignorance of memcg association makes it impossible to correctly restrict cpusets.mems during migration. So the clean logical divide makes a lot of sense for separating the high-level cgroup association, compression, etc. from the physical location of the memory and migration / zpdesc compaction, but it would appear that this comes at a cost of oversimplifying the logic and missing out on accurate memory charging and a unified source of truth for the counters. The last thing I wanted to note was that I agree that zsmalloc doing explicit zswap stat updates feels a bit awkward. The reason I chose to do this right now is because when enlightening zsmalloc about the compressed objs' objcgs, zswap is the only one that does this memory accounting. So having an objcg is a bit of a proxy to understand that the consumer is zswap (as opposed to zram). Of course, if zram starts to do memcg accounting as well, we'll have to start doing some other checks to see if the compresed object should be accounted as zram or zswap. OK. That's all the defense I have for my design : -) Now for thinking about other designs: I also explored whether it makes sense to make zsmalloc call a hook into zswap code during and after migrations. The problem is that there isn't a good way to do the compressed object --> zswap entry lookup, and this still doesn't solve the issue of zsmalloc migrating compressed objects without checking whether that object can live on another node. Maybe one possible approach is to turn the array of objcgs into an array of backpointers from compressed objects to their corresponding zswap_entries? One concern is that this does add 8 bytes of additional overhead per zswap entry, and I'm not sure that this is acceptable. I'll keep thinking on whether there's a creative way to save some memory here, though... Of course the other concern is what this will look like for zram users. I guess it can be done similarly to what is done here, and only allocate the array of pointers when called in from zswap. Anyways, thank you for bringing this up. What do you think about the options we have here? I hope that I've motivated why we want per-memcg-lruvec accounting as well. Please let me know if there is anything I can provide additional context for : -) Have a great day! Joshua