> One more point.> > > Sometimes the VM spends the first few priority rounds rotating back> > referenced pages and submitting IO. Once we get to a lower priority,> > sometimes the VM ends up freeing way too many pages.> > > > The fix is relatively simple: in shrink_zone() we can check how many> > pages we have already freed and break out of the loop.> > > > However, in order to do this we do need to know how many pages we already> > freed, so move nr_reclaimed into scan_control.> > IIRC, Balbir-san explained the implemetation of the memcgroup > force cache dropping feature need non bail out at the past reclaim > throttring discussion.> > I am not sure about this still right or not (iirc, memcgroup implemetation> was largely changed).> > Balbir-san, Could you comment to this patch?> > I'm not Balbir-san but there is no "force-cache-dropping" feature now.(I have no plan to do that.)

But, mem+swap controller will need to modify reclaim path to do "cache dropfirst" becasue the amount of "mem+swap" will not change when "mem+swap" hitlimit. It's now set "sc.may_swap" to 0.

Hmm, I hope memcg is a silver bullet to this kind of special? workload inlong term.