Re: [PATCH] mm: don't SetPageWorkingset unconditionally during swapin

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Dec 09, 2020 at 10:18:22AM +0100, Vlastimil Babka wrote:
> On 12/9/20 2:24 AM, Yu Zhao wrote:
> > We are capable of SetPageWorkingset based on refault distances after
> > commit aae466b0052e ("mm/swap: implement workingset detection for anonymous LRU")
> > This is done by workingset_refault(), which is right above the
> > unconditional SetPageWorkingset deleted by this patch.
> > 
> > The unconditional SetPageWorkingset miscategorizes pages that are
> > read ahead or never belonged to the working set (e.g., tmpfs pages
> > accessed by fd). When those pages are swapped in (after they were
> > swapped out) for the first time, they skew PSI (when using
> > async swap). When this happens again, depending on their refault
> > distances, they might skew workingset_restore_anon counter in
> > addition to PSI because their shadows say they were part of the
> > working set.
> > 
> > Signed-off-by: Yu Zhao <yuzhao@xxxxxxxxxx>
> 
> Acked-by: Vlastimil Babka <vbabka@xxxxxxx>
> 
> Makes sense, especially now that we have anonymous LRU support. The flag setting
> in this context seems to go back all the way to 1899ad18c607 ("mm: workingset:
> tell cache transitions from workingset thrashing") where I'm not sure why it was
> even used on the anonymous page, when workingset was only implemented for the
> page cache. Maybe Johannes remembers?

I just double checked that commit and the changelog is indeed
incomplete and doesn't mention the swap aspect. :(

That patch was part of the psi series. It was meant to mark incoming
pages under IO with SetPageWorkingset when waiting for them
constituted a memory stall.

On the page cache side, because we HAVE workingset detection, this was
specific to recently evicted pages that had been active in their
previous life. On the anon side, the aging algorithm had no
distinction between workingset and sporadically used pages. Given the
choice between a) no swapin stalls are pressure and b) all swapin
stalls are pressure, I went with the latter in order to detect swap
storms. The false positive case - high rate of swapin without severe
memory pressure - was relatively unlikely, because we tried to avoid
swapping until everything was completely on fire in the first place.

With the lru balancing rework, more prevalent use of proactive reclaim
etc. the distinction between hot and cold swapins became more
important. Thankfully, Joonsoo's patches made that possible.




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux