public inbox for cgroups@vger.kernel.org
 help / color / mirror / Atom feed
From: Johannes Weiner <hannes@cmpxchg.org>
To: "Michal Koutný" <mkoutny@suse.com>
Cc: Yosry Ahmed <yosryahmed@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Shakeel Butt <shakeelb@google.com>,
	Michal Hocko <mhocko@kernel.org>,
	Roman Gushchin <roman.gushchin@linux.dev>,
	Muchun Song <muchun.song@linux.dev>,
	linux-mm@kvack.org, cgroups@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/2] mm: memcg: refactor page state unit helpers
Date: Wed, 4 Oct 2023 14:36:19 -0400	[thread overview]
Message-ID: <20231004183619.GB39112@cmpxchg.org> (raw)
In-Reply-To: <vet5qmfj5xwge4ebznzihknxvpmrmkg6rndhani3fk75oo2rdm@lk3krzcresap>

On Wed, Oct 04, 2023 at 11:02:11AM +0200, Michal Koutný wrote:
> On Tue, Oct 03, 2023 at 12:47:25PM -0700, Yosry Ahmed <yosryahmed@google.com> wrote:
> > Those constants are shared with code outside of memcg, namely enum
> > node_stat_item and enum vm_event_item, and IIUC they are used
> > differently outside of memcg. Did I miss something?
> 
> The difference is not big, e.g.
>   mod_lruvec_state(lruvec, WORKINGSET_ACTIVATE_BASE + type, delta);
> could be
>   __count_memcg_events(
>     container_of(lruvec, struct mem_cgroup_per_node, lruvec)->memcg,
>     WORKINGSET_ACTIVATE_BASE + type, delta
>   );
> 
> Yes, it would mean transferring WORKINGSET_* items from enum
> node_stat_item to enum vm_event_item.
> IOW, I don't know what is the effective difference between
> mod_memcg_lruvec_state() and count_memcg_events().
> Is it per-memcg vs per-memcg-per-node resolution?

Yes, it's because of node resolution which event counters generally
don't have. Some of the refault events influence node-local reclaim
decisions, see mm/vmscan.c::snapshot_refaults().

There are a few other event counters in the stat array that people
thought would be useful to have split out in
/sys/devices/system/node/nodeN/vmstat to understand numa behavior
better.

It's a bit messy.

Some events would be useful to move to 'stats' for the numa awareness,
such as the allocator stats and reclaim activity.

Some events would be useful to move to 'stats' for the numa awareness,
but don't have the zone resolution required by them, such as
kswapd/kcompactd wakeups.

Some events aren't numa specific, such as oom kills, drop_pagecache.

  parent reply	other threads:[~2023-10-04 18:36 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-22 17:57 [PATCH v2 0/2] mm: memcg: fix tracking of pending stats updates values Yosry Ahmed
     [not found] ` <20230922175741.635002-1-yosryahmed-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2023-09-22 17:57   ` [PATCH v2 1/2] mm: memcg: refactor page state unit helpers Yosry Ahmed
2023-10-03 13:03     ` Johannes Weiner
2023-10-03 18:11     ` Michal Koutný
2023-10-03 19:47       ` Yosry Ahmed
2023-10-04  9:02         ` Michal Koutný
2023-10-04 16:58           ` Yosry Ahmed
2023-10-04 18:36           ` Johannes Weiner [this message]
2023-10-05  9:06             ` Michal Koutný
2023-10-05  9:31               ` Yosry Ahmed
2023-10-05 16:30                 ` Michal Koutný
2023-10-05 17:30                   ` Yosry Ahmed
2023-10-18 19:27                     ` Andrew Morton
2023-09-22 17:57   ` [PATCH v2 2/2] mm: memcg: normalize the value passed into memcg_rstat_updated() Yosry Ahmed
2023-10-03 13:13     ` Johannes Weiner
2023-10-03 15:53       ` Yosry Ahmed
2023-10-03 18:22     ` Michal Koutný
2023-10-03 19:51       ` Yosry Ahmed
2023-09-25 13:50   ` [PATCH v2 0/2] mm: memcg: fix tracking of pending stats updates values Michal Hocko
2023-09-25 13:50     ` Michal Hocko
     [not found]     ` <ZRGQIhWF02SRzN4D-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2023-09-25 17:11       ` Yosry Ahmed
2023-09-25 17:11         ` Yosry Ahmed
2023-10-03  7:57         ` Michal Hocko
2023-10-03  8:03           ` Yosry Ahmed
2023-10-03  8:09             ` Michal Hocko
2023-10-03  8:49               ` Yosry Ahmed

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=20231004183619.GB39112@cmpxchg.org \
    --to=hannes@cmpxchg.org \
    --cc=akpm@linux-foundation.org \
    --cc=cgroups@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=mkoutny@suse.com \
    --cc=muchun.song@linux.dev \
    --cc=roman.gushchin@linux.dev \
    --cc=shakeelb@google.com \
    --cc=yosryahmed@google.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox