From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oa1-f41.google.com (mail-oa1-f41.google.com [209.85.160.41]) (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 8BAB237EFE6 for ; Fri, 26 Jun 2026 20:18:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782505139; cv=none; b=RiuctFzg9BfjIVZBOZF79b63v6MGqVqIcKPIh6HarKig6azXfdy6wZR4R4Lcys6XjDANVxpH99gn/+pRRFLIOIZSxdEKzJ+SbAEkPQykt2Ag15cyS4jKOPpfDzmCA325KvoPN5hTafyg0BfZUV4J4RyiwJ+Y/7mRfx7gEbhpeCU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782505139; c=relaxed/simple; bh=kPGPSVS+tn0YoMexJTZ/d99RoTmnxrVbq42SNtfTZJU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=QuiVJFrU0cD5IimYBJSF4q0JMZwjHod7zXqTfQq5E1KGRkGUY0YJ+qbNpFdoYM27wx0T6wCGXgFp7hE7pIjLHgOX8oCMntNzXMQAsKiR9bbIU9K28IRpy2wDU8HpBjrjZ5IV3k5mBu6AwPV1YoYBdtTWLGxqgiErrgjVzfT3BvI= 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=cJJDDLVN; arc=none smtp.client-ip=209.85.160.41 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="cJJDDLVN" Received: by mail-oa1-f41.google.com with SMTP id 586e51a60fabf-447d86f63c8so646655fac.1 for ; Fri, 26 Jun 2026 13:18:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1782505137; x=1783109937; 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=RGjlyDYhehErqYiWQ+JPN847GkKF9E5lFSL9mEIK8Uc=; b=cJJDDLVNUVrquSpapjdOI8avSHT9vDlM+aQzaYGK1LeawpapqpuUteFGGyWNAeE9Zy 97mRc1GayACVUCl7/hc4pmqtXXEzwEFqvA+uTjJ8jC9e6l/JT3prBG8OZd6dZFkSJ1p1 r7Yr+/n8N6vYhM7oDzz8SlkCGrAXeoIFpS/OkwLJwhSNWkjDk3XCXibr1Tg2AMcSsfdd 8MQlpmLY3jgqz2LxCYDJF435YnioYWJj9wDj5h7PdU+3Q0BTGICU6OmsnJftkNFXtU0n Jmmab7Eecl/pdP1lvGhtDNV6ZKfGOY45+zb+wIzquSHFcixUgxVcLvV1sXyBDowHkrrG bHHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782505137; x=1783109937; 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=RGjlyDYhehErqYiWQ+JPN847GkKF9E5lFSL9mEIK8Uc=; b=rGADgAAz6msGsz/nrK4irifvOZ6746dd2fods/pzxdy52k5zPBqTLu4C4L8zB/CDsh zJqg89I8RzyDwvtiQa9jgLImbBy9DSfwOffax9Jm9IRupk86FufXZnHhdzlExbiVefaT CYNCLeqJQ8iQPofi1WubiFDmK8OGe6ppQxn+C8XEg+ZAU80SIZ3/bi+gHJyYERpGtVhC BE7QG+OzhuRGIT/I2h/TaOKwkFPpyRUJF9aVHM+RXwfbsQbpgm8G4feqXdUrKTNh7UjG atjkL+xPtM1EtbMNbXKjZ2dMybnlDAw7XVfbWZizBAB2o5COsX/LWbvlIrnD5W2RUqr7 maQg== X-Forwarded-Encrypted: i=1; AHgh+RrUf8qCJcwBnxFtY/c1DcccH2LVHaPqOgD23EYzfwLwXgkvWB5JanrHmnPfXuXId44PthISpEE+dnEqZPo=@vger.kernel.org X-Gm-Message-State: AOJu0Yyk6JYJ+KoPDAjzlrgkgpQULFxhCl+42FRVrrt4kI8Dp52PmGeN kzZ+w9Mah/MgpBKPM1DbH3pyyyQ1F2Y8vAgcJL4k2Yu9A+cw1QJopUoD X-Gm-Gg: AfdE7cnYqpPoq0Sb1iJvpZJ57a5m4wDX8ctMRcJKIE7rrlkSJip8vOtyW8X+oFW/iuJ Z0E7hpaic5FKNoUfReH8VRcBybktKXBOvmztXoPnerg3mQkupnKVF8Tch8JNtsytuS5a+WnJUtA nidVzrFUQlwF3XGtvUZ9SHAZJssCnc0iRx1XCSkdxlte88kBi7488Udh+X3tz90gpTVYTX92kd6 mHOEWHU0vH7G4F8qG62vuDKtS3w0gmJmZ5khnwbv2AQHuiP4A+cLmR0n5nz0qVXGWtfcUEseqIU rh7z/1OrcYVPe55x/WtPmo4b2hKXI8vHUg7mXEzAtPQnSA2RyBlCkvs5u1w2/uVUMugjEH2SOYO 0F7tV8cpUyBDihMibKe4tW9BvyMCTwSQVG+1vYienvk/S1yxRXrwiJFeFxAt64Fn8/vrdAIQG0L G5kKex7c6uAJU/Zx5Ml6kSTS0V5kK3T+WqTbSRq30B6J4= X-Received: by 2002:a05:6870:c0d0:b0:441:d09:7f6 with SMTP id 586e51a60fabf-448119a0600mr7118160fac.4.1782505137237; Fri, 26 Jun 2026 13:18:57 -0700 (PDT) Received: from localhost ([2a03:2880:10ff:55::]) by smtp.gmail.com with ESMTPSA id 586e51a60fabf-4472e79af8fsm14027490fac.0.2026.06.26.13.18.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Jun 2026 13:18:56 -0700 (PDT) From: Joshua Hahn To: Joshua Hahn Cc: Johannes Weiner , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R . Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@meta.com Subject: Re: [PATCH v4 0/5] mm/memcontrol, page_counter: move stock from mem_cgroup to page_counter Date: Fri, 26 Jun 2026 13:18:54 -0700 Message-ID: <20260626201855.2966118-1-joshua.hahnjy@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260623180124.868655-1-joshua.hahnjy@gmail.com> 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, 23 Jun 2026 11:01:18 -0700 Joshua Hahn wrote: > This series is intended for the next release cycle. > > v3 --> v4 > ========= > - Reduced memory footprint by 4x, from 16 bytes per-(cpu x memcg) to > 4 bytes per-(cpu x memcg). Each page_counter_stock is a thin wrapper > around an atomic_t. > - Removed locking completely and uses atomic operations to use stock. > - Removed synchronous work_on_cpu. All work is done via remote > atomic_xchgs. > - Added a patch to flatten page_counter charging in try_charge_memcg > - Split page_counter_try_charge into stocked and non-stocked variants. > > INTRO > ===== > Memcg currently keeps a "stock" of 64 pages per-cpu to cache pre-charged > allocations, allowing small and frequent allocations to avoid walking > the expensive mem_cgroup hierarchy traversal each time. This fastpath > offers real improvements, but there is room for improvement: > > 1. Currently, each CPU tracks up to 7 (NR_MEMCG_STOCK) mem_cgroups. When > more than 7 mem_cgroups have stock present on a single CPU, a random > victim is evicted and its associated stock is drained. > > 2. When one cgroup runs out of memory and needs to drain stock across > all CPUs it has stock cached in, those CPUs will drain all other > memcgs' stock present in that CPU. This leads to inefficient stock > caching and cross-memcg interference under memory pressure. > > 3. Stock management is tightly coupled to struct mem_cgroup, which makes > it difficult to add a new page_counter to mem_cgroup and have > multiple sources of stock management. > > This series moves the per-cpu stock down into page_counter which > consolidates stock limit checking and page_counter limit checking into > page_counter_try_charge_stock. This eliminates the 7 memcg-per-cpu slot > limit, the random cross-memcg stock drains, and slot traversal. We also > simplify memcontrol code, since we no longer need to maintain separate > draining functions or manage the asynchronous workqueue. Hello, I just want to address a few things that Sashiko raised. I think there are definitely some improvements that I can make as Sashiko suggested. In commit 3/5 mm/page_counter: introduce page_counter_try_charge_stock() Sashiko raises two concerns. "Can the per-CPU stock grow unboundedly beyond counter->batch pages here?" I think this is true. I went back to the original stock design and saw that when the stock is greater than the batch size, it just drains all of it (since this means we raced). I can add the same check so that we never grow beyond the batch size. This should also help with the point below. "Does moving the per-CPU cache from a single shared stock to a per-page_counter stock fundamentally change the memory stranding bounds?" This is true, and I addressed this in the cover letter. Yes, the worst-case upper bound grows by quite a bit, but it is difficult to hit that limit since it would require a memcg process to be scheduled on all the CPUs, and strand memory there via the stock. Nonetheless, restricting the batch size should make this worst-case a bit better. In commit 4/5 mm/memcontrol: convert memcg to use page_counter_stock() Sashiko also raises two concerns. "Could this synchronous loop cause cacheline bouncing and premature OOM kills?" Sashiko is referring to the memcg-cpu iteration we do where we drain the stock of an entire descendant completely. I also addressed this in the cover letter and that I couldn't really reproduce the issue in my testing. I addressed this every version but it seems like Sashiko does not read the cover letter :' ( "Would doing a volatile read to check if the stock has pages before calling atomic_xchg() help mitigate this?" This one I agree with, I'll add: if (!atomic_read(&stock->nr_pages)) return; nr_pages = atomic_xchg(&stock->nr_pages, 0); And hopefully we can avoid most of the unnecsesary races (of course the value can still change in between the read and the atomic_xchg but it's just a best-effort optimization) So I'll spin up a v5. One thing I'm going back and forth in my mind is whether we want separate stocked and non-stocked variants, or if that should just happen transparently within the calls. Thanks again Sashiko! Joshua