Re: [patch] mm: remove sysctl to manually rescue unevictable pages

[Johannes Weiner]

On Mon, Sep 26, 2011 at 05:40:52PM +0530, kautuk.c @samsung.com wrote:
> On Mon, Sep 26, 2011 at 4:59 PM, Johannes Weiner <jweiner@xxxxxxxxxx> wrote:
> > On Sun, Sep 25, 2011 at 04:29:40PM +0530, Kautuk Consul wrote:
> >> write_scan_unavictable_node checks the value req returned by
> >> strict_strtoul and returns 1 if req is 0.
> >>
> >> However, when strict_strtoul returns 0, it means successful conversion
> >> of buf to unsigned long.
> >>
> >> Due to this, the function was not proceeding to scan the zones for
> >> unevictable pages even though we write a valid value to the
> >> scan_unevictable_pages sys file.
> >
> > Given that there is not a real reason for this knob (anymore) and that
> > it apparently never really worked since the day it was introduced, how
> > about we just drop all that code instead?
> >
> >        Hannes
> >
> > ---
> > From: Johannes Weiner <jweiner@xxxxxxxxxx>
> > Subject: mm: remove sysctl to manually rescue unevictable pages
> >
> > At one point, anonymous pages were supposed to go on the unevictable
> > list when no swap space was configured, and the idea was to manually
> > rescue those pages after adding swap and making them evictable again.
> > But nowadays, swap-backed pages on the anon LRU list are not scanned
> > without available swap space anyway, so there is no point in moving
> > them to a separate list anymore.
> 
> Is this code only for anonymous pages ?
> It seems to look at all pages in the zone both file as well as anon.

The code scans both, but the usecase I described was moving swapbacked
pages from the unevictable list after configuring swap space.

> > The manual rescue could also be used in case pages were stranded on
> > the unevictable list due to race conditions.  But the code has been
> > around for a while now and newly discovered bugs should be properly
> > reported and dealt with instead of relying on such a manual fixup.
> 
> What you say seems to be all right for anon pages, but what about file
> pages ?
> I'm not sure about how this could happen, but what if some file-system caused
> a file cache page to be set to evictable or reclaimable without
> actually removing
> that page from the unevictable list ?

Currently, unevictable file pages come from ramfs, shmem, and mlock.
ramfs never makes them evictable.  shmem, after making an inode
evictable again, scans the that inode's address_space and rescues the
pages it finds.  munlock synchroneously rescues the pages vma's range.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/