Re: [PATCH 0/9 RFC] cgroup: separate rstat trees

[Shakeel Butt <shakeel.butt@linux.dev>]

On Wed, Jan 08, 2025 at 07:16:47PM +0100, Michal Koutný wrote:
> Hello JP.
> 
> On Mon, Dec 23, 2024 at 05:13:53PM -0800, JP Kobryn <inwardvessel@gmail.com> wrote:
> > I've been experimenting with these changes to allow for separate
> > updating/flushing of cgroup stats per-subsystem.
> 
> Nice.
> 
> > I reached a point where this started to feel stable in my local testing, so I
> > wanted to share and get feedback on this approach.
> 
> The split is not straight-forwardly an improvement --

The major improvement in my opinion is the performance isolation for
stats readers i.e. cpu stats readers do not need to flush memory stats.

> there's at least
> higher memory footprint 

Yes this is indeed the case and JP, can you please give a ballmark on
the memory overhead?

> and flushing efffectiveness depends on how
> individual readers are correlated, 

Sorry I am confused by the above statement, can you please expand on
what you meant by it?

> OTOH writer correlation affects
> updaters when extending the update tree.

Here I am confused about the difference between writer and updater.

> So a workload dependent effect
> can go (in my theory) both sides.
> There are also in-kernel consumers of stats, namely memory controller
> that's been optimized over the years to balance the tradeoff between
> precision and latency.

In-kernel memcg stats readers will be unaffected most of the time with
this change. The only difference will be when they flush, they will only
flush memcg stats.

> 
> So do you have any measurements (or expectations) that show how readers
> or writers are affected?
> 

Here I am assuming you meant measurements in terms of cpu cost or do you
have something else in mind?


Thanks a lot Michal for taking a look.