Hi, Thanks for looking into this patch, Greg Thelen <gthelen@xxxxxxxxxx> writes: > Vaibhav Jain <vaibhav@xxxxxxxxxxxxx> wrote: > >> [1] Provides a way for user-space to trigger proactive reclaim by introducing >> a write-only memcg file 'memory.reclaim'. However reclaim stats like number >> of pages scanned and reclaimed is still not directly available to the >> user-space. >> >> This patch proposes to extend [1] to make the memcg file 'memory.reclaim' >> readable which returns the number of pages scanned / reclaimed during the >> reclaim process from 'struct vmpressure' associated with each memcg. This should >> let user-space asses how successful proactive reclaim triggered from memcg >> 'memory.reclaim' was ? >> >> With the patch following command flow is expected: >> >> # echo "1M" > memory.reclaim >> >> # cat memory.reclaim >> scanned 76 >> reclaimed 32 > > I certainly appreciate the ability for shell scripts to demonstrate > cgroup operations with textual interfaces, but such interface seem like > they are optimized for ease of use by developers. > Agree that directly exposing nr_scanned/reclaimed might not be a useful for users and certainly looks like a dev interface > I wonder if for runtime production use an ioctl or netlink interface has > been considered for cgroup? I don't think there are any yet, but such > approaches seem like a more straightforward ways to get nontrivial > input/outputs from a single call (e.g. like this proposal). And they > have the benefit of not requiring ascii serialization/parsing overhead. I think to a large degree eBPF and existing static tracepoints in vmscan can provide access to these metrics as Shakeel Bhat pointed to earlier. <snip> -- Cheers ~ Vaibhav
