Re: [PATCH 1/2] cgroup/dmem: add per-region event counters

[Hongfu Li]

Hi,

On 6/25/26 4:57 PM, Natalie Vock wrote:
> Hi,
>
> On 6/25/26 04:10, Hongfu Li wrote:
> > Hi, Tejun
> > Thanks for the review comments.
> >
> > > > Add dmem.events to report hierarchical low/max event counts per DMEM
> > > > region.  Increment counters on dmem.max allocation failures and
> > > > dmem.low protection events.  The file is available for non-root 
> > > > cgroups
> > > > only.
> > >
> > > Please don't double space in descs or comments. Also, maybe it's 
> > > obvious but
> > > it'd help if you list why and how this is useful. Why do we want to add
> > > this?
> >
> > I'll fix the double spacing in the commit message and comments.
> >
> > As for the motivation: dmem already exposes per-region limits and 
> > current
> > usage, but not how often those limits actually matter at runtime. 
> > Without
> > event counters, it's hard to tell whether allocation failures come from
> > this cgroup, a parent limit, or pressure elsewhere in the hierarchy.
> > dmem.events provides that visibility for tuning dmem.low/dmem.max and
> > diagnosing recurring device memory pressure.
>
> Shouldn't you be able to deduce this rather trivially from just 
> looking at the current usage together with the low/max limits you 
> already set? I'm not sure I really see anything this events file 
> provides that analysis of current usage and set limits doesn't? If 
> your usage is highly variable, the separately-developed dmem.peak file 
> might also suit your needs, but still, not sure what you can do with 
> dmem.events that you can't already do with these tools. 
Thanks for the question.

Besides exposing counters, dmem.events notifies userspace on changes via
cgroup_file_notify(). This allows tools to monitor limit-related events
(for example, allocation failures or low-protection fallbacks) 
asynchronously,
without the need to periodically poll dmem.current against the limits. 
While
you could infer some conditions from current usage and limits, polling is
inefficient and cannot capture transient events in real time. dmem.peak only
records the highest usage, not these specific events.

So dmem.events provides both lower overhead and richer, actionable 
information.

Best regards,
Hongfu