On Fri, 11 Feb 2022, Vlastimil Babka wrote: > On 2/6/22 22:49, Hugh Dickins wrote: > > > > Any new pagevec runs the risk of adding a new way of stranding, and we > > might discover other corners where mlock_page_drain() or lru_add_drain() > > would now help. If the mlock pagevec raises doubts, we can easily add a > > sysctl to tune its length to 1, which reverts to synchronous operation. > > Not a fan of adding new sysctls like those as that just pushes the failure > of kernel devs to poor admins :) > The old pagevec usage deleted by patch 1 was limited to the naturally larger > munlock_vma_pages_range() operation. The new per-cpu based one is more > general, which obviously has its advantages, but then it might bring new > corner cases. > So if this turns out to be an big problem, I would rather go back to the > limited scenario pagevec than a sysctl? Okay, I'll delete that comment proposing a sysctl, which was more as a possible safety measure for our internal experimentation than for general use. I just thought it was an easy way to force synchronous. I don't expect a big problem. The flush in this commit deals, I think, with the only way it was treading on its own toes, using a pagevec at a level which relied on the unlikelihood of a pagevec reference. But I can imagine that such-and-such a test will expect Mlocked or Unevictable to be exact, and this pagevec now delay it becoming exact. I've not seen any example so far, but it does seem possible. Maybe we shall fix the test, maybe we shall add a drain. I hadn't thought of limiting the use of pagevec to the mass operation (if a significant problem emerges). Yes, that might be a better idea, thanks. Anyway, we don't need to worry in advance. A change I also had in this patch, orginally, was for /proc/sys/vm/stat_refresh to lru_add_drain_all() first. I'm surprised that tests see good numbers without it doing so; but since I've not actually seen the need for it yet, dropped that - we can always add it later if need emerges. Hugh
