Hi, Thanks for looking into this patch, Shakeel Butt <shakeelb@xxxxxxxxxx> writes: > On Thu, May 19, 2022 at 04:08:15AM +0530, Vaibhav Jain 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 >> > > Yosry already mentioned the race issue with the implementation and I > would prefer we don't create any new dependency on vmpressure which I > think we should deprecate. Ok, > > Anyways my question is how are you planning to use these metrics i.e. > scanned & reclaimed? I wonder if the data you are interested in can be > extracted without a stable interface. Have you tried BPF way to get > these metrics? We already have a tracepoint in vmscan tracing the > scanned and reclaimed. > Agree that there are enough static trace_mm_vmscan_ tracepoints in vmscan to get that info. Also agree that exposing nr_scanned/nr_reclaimed directly to userspace may not be a good idea but knowing the amount of memory reclaimed might be useful. With user-space triggered proactive reclaim user-space code can try to write a certain value to "memory.reclaim" in a loop till it returns '-EBUSY'. Right now there is no direct way for it to get feedback on the progress of the requested reclaim. Providing a stable interface to ascertain the progress of reclaim lets that userspace provide smaller values for proactive reclaim -- Cheers ~ Vaibhav
