lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJD7tkYCERG5pUTcdmw8UGks8wtK9W9jzZGZODE6sZ-9-WEv-g@mail.gmail.com>
Date: Fri, 26 Jul 2024 10:43:31 -0700
From: Yosry Ahmed <yosryahmed@...gle.com>
To: Shakeel Butt <shakeel.butt@...ux.dev>
Cc: Andrew Morton <akpm@...ux-foundation.org>, Johannes Weiner <hannes@...xchg.org>, 
	Michal Hocko <mhocko@...nel.org>, Roman Gushchin <roman.gushchin@...ux.dev>, 
	Muchun Song <muchun.song@...ux.dev>, Greg Thelen <gthelen@...gle.com>, 
	Facebook Kernel Team <kernel-team@...a.com>, linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] memcg: expose children memory usage for root

On Fri, Jul 26, 2024 at 10:30 AM Shakeel Butt <shakeel.butt@...ux.dev> wrote:
>
> On Fri, Jul 26, 2024 at 09:25:27AM GMT, Yosry Ahmed wrote:
> > On Fri, Jul 26, 2024 at 8:48 AM Shakeel Butt <shakeel.butt@...ux.dev> wrote:
> > >
> [...]
> > >
> > > No, the workloads running in non-root memcgs will not see any
> > > difference. Only the workloads running in root will see charging
> > > overhead.
> >
> > Oh yeah we already charge the root's page counters hierarchically in
> > the upstream kernel, we just do not charge them if the origin of the
> > charge is the root itself.
> >
> > We also have workloads that iterate top-level memcgs to calculate the
> > total charged memory, so memory.children_usage for the root memcg
> > would help.
> >
> > As for memory.current, do you have any data about how much memory is
> > charged to the root itself? We think of the memory charged to the root
> > as system overhead, while the memory charged to top-level memcgs
> > isn't.
> >
> > So basically total_memory - root::memory.children_usage would be a
> > fast way to get a rough estimation of system overhead. The same would
> > not apply for total_memory - root::memory.current if I understand
> > correctly.
>
> Please note that root::memory.children_usage will have top level zombies
> included as well (at least until lru reparenting is not done). So, for
> your example it would provide good estimation of top level zombie memory
> through root::memory.children_usage - top_level(alive)::memory.current.

Good point. The fact that it includes the top-level zombies makes it
less valuable for this use case, as zombie memory is considered system
overhead as well. So we need to iterate the top level memcgs anyway.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ