Hi, > > > > > > 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. > > Agreed, they're separate but both useful. > > The peak tells you what the maximum memory consumption is. > The events are sent when a limit is reached, but more will also count how > often limit is reached and reclaim needs to happen. > > So if you have 4 cgroups, and 1 of them sends a lot of events, that tells you > that you may want > to increase that cgroup's limits dynamically to have a more performant system.
Thanks for the reply. That clarifies the distinction between peak and events nicely. While implementing the low event counter, I hit a design mismatch with how TTM eviction works. TTM keeps BO LRUs per ttm_resource_manager (per memory type), not per cgroup. During eviction, dmem_cgroup_state_evict_valuable() is called for each BO on that global LRU. If we increment the low counter inside this per-BO check for pools protected by dmem.low, we count once per rejected BO during the scan, not once per low-protection fallback. Memory cgroup avoids this: reclaim is per memory cgroup, and MEMCG_LOW is incremented once per memcg when reclaim enters the low-protection fallback, before page scanning, not once per page examined. For dmem, the low counter should be bumped when eviction decides to fall back, when hit_low triggers a retry with try_low = true, not inside the per-BO iteration. I'll revise the series accordingly for v2. Thanks again for your feedback. Best regards, Hongfu
