From: Shakeel Butt <shakeel.butt@linux.dev>
To: Harry Yoo <harry@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@kernel.org>,
Roman Gushchin <roman.gushchin@linux.dev>,
Muchun Song <muchun.song@linux.dev>,
Qi Zheng <qi.zheng@linux.dev>, Alexandre Ghiti <alex@ghiti.fr>,
Joshua Hahn <joshua.hahnjy@gmail.com>,
Meta kernel team <kernel-team@meta.com>,
linux-mm@kvack.org, cgroups@vger.kernel.org,
linux-kernel@vger.kernel.org,
kernel test robot <oliver.sang@intel.com>
Subject: Re: [PATCH 2/4] memcg: uint16_t for nr_bytes in obj_stock_pcp
Date: Wed, 20 May 2026 18:01:30 -0700 [thread overview]
Message-ID: <ag5ZXSKgUz3tt4mV@linux.dev> (raw)
In-Reply-To: <55d36f91-fcae-4506-9b76-4a7cad3d256d@kernel.org>
On Wed, May 20, 2026 at 04:01:45PM +0900, Harry Yoo wrote:
>
>
> On 5/20/26 2:31 PM, Shakeel Butt wrote:
> > Currently struct obj_stock_pcp stores nr_bytes in an 'unsigned int'
> > which is 4 bytes on 64-bit machines. Switch the field to uint16_t to
> > shrink the per-CPU cache.
> >
> > The kernel supports PAGE_SIZE_4KB, _8KB, _16KB, _32KB, _64KB and
> > _256KB (see HAVE_PAGE_SIZE_* in arch/Kconfig). After the
> > PAGE_SIZE-aligned flush in __refill_obj_stock(), the sub-page
> > remainder fits in uint16_t up through 64KiB pages where PAGE_SIZE - 1
> > == U16_MAX, but on 256KiB pages PAGE_SIZE - 1 == 0x3FFFF exceeds
> > U16_MAX. The accumulator also needs to stay within uint16_t between
> > page-aligned flushes on 64KiB pages where PAGE_SIZE itself is
> > U16_MAX + 1.
> >
> > Accumulate the new total in an 'unsigned int' local, then:
> >
> > 1. Flush whenever the accumulator would hit U16_MAX. Together with
> > the existing allow_uncharge flush at PAGE_SIZE, this keeps the
> > uint16_t safe on PAGE_SIZE <= 64KiB.
> >
> > 2. On configs with PAGE_SHIFT > 16 (PAGE_SIZE_256KB on hexagon and
> > powerpc 44x), push any sub-page remainder above U16_MAX into
> > objcg->nr_charged_bytes via atomic_add before storing back, so
> > the store cannot silently truncate. The PAGE_SHIFT > 16 guard
> > folds the branch out at compile time on smaller page sizes.
> >
> > Signed-off-by: Shakeel Butt <shakeel.butt@linux.dev>
> > Tested-by: kernel test robot <oliver.sang@intel.com>
> > ---
> > mm/memcontrol.c | 33 +++++++++++++++++++++++++++------
> > 1 file changed, 27 insertions(+), 6 deletions(-)
> >
> > diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> > index d7c162946719..b3d63d9f267c 100644
> > --- a/mm/memcontrol.c
> > +++ b/mm/memcontrol.c
> > @@ -3339,21 +3340,41 @@ static void __refill_obj_stock(struct obj_cgroup *objcg,
> > goto out;
> > }
> > + stock_nr_bytes = stock->nr_bytes;
> > if (READ_ONCE(stock->cached_objcg) != objcg) { /* reset if necessary */
> > drain_obj_stock(stock);
> > obj_cgroup_get(objcg);
> > - stock->nr_bytes = atomic_read(&objcg->nr_charged_bytes)
> > + stock_nr_bytes = atomic_read(&objcg->nr_charged_bytes)
> > ? atomic_xchg(&objcg->nr_charged_bytes, 0) : 0;
> > WRITE_ONCE(stock->cached_objcg, objcg);
> > allow_uncharge = true; /* Allow uncharge when objcg changes */
> > }
> > - stock->nr_bytes += nr_bytes;
> > + stock_nr_bytes += nr_bytes;
> > +
> > + /* Since stock->nr_bytes is uint16_t, don't refill >= U16_MAX */
> > + if ((allow_uncharge && (stock_nr_bytes > PAGE_SIZE)) ||
> > + stock_nr_bytes >= U16_MAX) {
>
> nit: This should be > U16_MAX?
Ack.
next prev parent reply other threads:[~2026-05-21 1:01 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-20 5:31 [PATCH 0/4] memcg: shrink obj_stock_pcp and cache multiple objcgs Shakeel Butt
2026-05-20 5:31 ` [PATCH 1/4] memcg: store node_id instead of pglist_data pointer Shakeel Butt
2026-05-20 6:01 ` Harry Yoo
2026-05-20 6:13 ` Muchun Song
2026-05-20 5:31 ` [PATCH 2/4] memcg: uint16_t for nr_bytes in obj_stock_pcp Shakeel Butt
2026-05-20 6:41 ` Harry Yoo
2026-05-20 7:01 ` Harry Yoo
2026-05-21 1:01 ` Shakeel Butt [this message]
2026-05-20 13:20 ` David Laight
2026-05-21 1:03 ` Shakeel Butt
2026-05-20 5:31 ` [PATCH 3/4] memcg: int16_t for cached slab stats Shakeel Butt
2026-05-20 7:25 ` Harry Yoo
2026-05-20 5:31 ` [PATCH 4/4] memcg: multi objcg charge support Shakeel Butt
2026-05-20 9:35 ` Harry Yoo
2026-05-21 1:05 ` Shakeel Butt
2026-05-21 1:43 ` Harry Yoo
2026-05-21 20:19 ` Shakeel Butt
2026-05-21 3:22 ` Joshua Hahn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ag5ZXSKgUz3tt4mV@linux.dev \
--to=shakeel.butt@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=alex@ghiti.fr \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=harry@kernel.org \
--cc=joshua.hahnjy@gmail.com \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=muchun.song@linux.dev \
--cc=oliver.sang@intel.com \
--cc=qi.zheng@linux.dev \
--cc=roman.gushchin@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.