On Thu, Nov 10, 2022 at 11:35 AM Yosry Ahmed <yosryahmed@xxxxxxxxxx> wrote: > > On Thu, Nov 10, 2022 at 6:42 AM Michal Koutný <mkoutny@xxxxxxxx> wrote: > > > > Hello Jialin. > > > > On Thu, Nov 10, 2022 at 02:53:16PM +0800, Lu Jialin <lujialin4@xxxxxxxxxx> wrote: > > > When user use memory.reclaim to reclaim memory, after drain percpu lru > > > caches, drain percpu charge caches for given memcg stock in the hope > > > of introducing more evictable pages. > > > > Do you have any data on materialization of this hope? > > > > IIUC, the stock is useful for batched accounting to page_counter but it > > doesn't represent real pages. I.e. your change may reduce the > > page_counter value but it would not release any pages. Or have I missed > > a way how it helps with the reclaim? > > +1 > > It looks like we just overcharge the memcg if the number of allocated > pages are less than the charging batch size, so that upcoming > allocations can go through a fast accounting path and consume from the > precharged stock. I don't understand how draining this charge may help > reclaim. > > OTOH, it will reduce the page counters, so if userspace is relying on > memory.current to gauge how much reclaim they want to do, it will make > it "appear" like the usage dropped. If userspace is using other > signals (refaults, PSI, etc), then we would be more-or-less tricking > it into thinking we reclaimed pages when we actually didn't. In that > case we didn't really reclaim anything, we just dropped memory.current > slightly, which wouldn't matter to the user in this case, as other > signals won't change. In fact, we wouldn't be tricking anyone because this will have no effect on the return value of memory.reclaim. We would just be causing a side effect of very slightly reducing memory.current. Not sure if this really helps. > > The difference in perceived usage coming from draining the stock IIUC > has an upper bound of 63 * PAGE_SIZE (< 256 KB with 4KB pages), I > wonder if this is really significant anyway. > > > > > Thanks, > > Michal