On Wed, Mar 05, 2025 at 05:07:04PM -0800, JP Kobryn <inwardvessel@xxxxxxxxx> wrote:
> When the entry point for flushing is reading the file memory.stat,
> memory_stat_show() is called which leads to __mem_cgroup_flush_stats(). In
> this function, there is an early return when (!force && !needs_flush) is
> true. This opportunity to "skip" a flush is not reached when another
> subsystem has initiated the flush and entry point for flushing memory is
> css->css_rstat_flush().
That sounds spot on, I'd say that explains the savings observed.
Could you add a note the next version along the lines like this:
memcg flushing uses heuristics to optimize flushing but this is
bypassed when memcg is flushed as consequence of sharing the
update tree with another controller.
IOW, other controllers did flushing work instead of memcg but it was
inefficient (effective though).
> Are you suggesting a workload with fewer threads?
No, no, I only roughly wondered where the work disappeared (but I've
understood it from the flushing heuristics above).
> > What's the change between control vs experiment? Runnning in root cg vs
> > nested? Or running without *.stat readers vs with them against the
> > kernel build?
> > (This clarification would likely answer my question above.)
> >
>
(reordered by me, hopefully we're on the same page)
before split:
> workload control with no readers:
> real 6m54.818s
> user 117m3.122s
> sys 5m4.996s
>
> workload control with constant readers {memory,io,cpu,cgroup}.stat:
> real 6m59.468s
> user 118m26.981s
> sys 5m20.163s
after split:
> workload experiment with no readers:
> real 6m54.862s
> user 117m12.812s
> sys 5m0.943s
>
> workload experiment with constant readers {memory,io,cpu,cgroup}.stat:
> real 6m57.031s
> user 118m13.833s
> sys 5m3.454s
I reckon this is positive effect* of the utilized heuristics (no
unnecessary flushes, therefore no unnecessary tree updates on writer
side neither).
*) Not statistical but it doesn't look worse.
> These tests were done in a child (nested) cgroup. Were you also asking for a
> root vs nested experiment or were you just needing clarification on the test
> details?
No, I don't think the root vs nested would be that much interesting in
this case.
Thanks,
Michal
Attachment:
signature.asc
Description: PGP signature
