Messages in this thread | | | Date | Mon, 24 Mar 2014 11:04:02 -0700 | Subject | Re: [PATCH 5/5] vmscan: Age anonymous memory even when swap is off. | From | John Stultz <> |
| |
On Mon, Mar 24, 2014 at 10:33 AM, Rik van Riel <riel@redhat.com> wrote: > On 03/21/2014 05:17 PM, John Stultz wrote: >> >> Currently we don't shrink/scan the anonymous lrus when swap is off. >> This is problematic for volatile range purging on swapless systems/ >> >> This patch naievely changes the vmscan code to continue scanning >> and shrinking the lrus even when there is no swap. >> >> It obviously has performance issues. >> >> Thoughts on how best to implement this would be appreciated. >> >> Cc: Andrew Morton <akpm@linux-foundation.org> >> Cc: Android Kernel Team <kernel-team@android.com> >> Cc: Johannes Weiner <hannes@cmpxchg.org> >> Cc: Robert Love <rlove@google.com> >> Cc: Mel Gorman <mel@csn.ul.ie> >> Cc: Hugh Dickins <hughd@google.com> >> Cc: Dave Hansen <dave@sr71.net> >> Cc: Rik van Riel <riel@redhat.com> >> Cc: Dmitry Adamushko <dmitry.adamushko@gmail.com> >> Cc: Neil Brown <neilb@suse.de> >> Cc: Andrea Arcangeli <aarcange@redhat.com> >> Cc: Mike Hommey <mh@glandium.org> >> Cc: Taras Glek <tglek@mozilla.com> >> Cc: Jan Kara <jack@suse.cz> >> Cc: KOSAKI Motohiro <kosaki.motohiro@gmail.com> >> Cc: Michel Lespinasse <walken@google.com> >> Cc: Minchan Kim <minchan@kernel.org> >> Cc: linux-mm@kvack.org <linux-mm@kvack.org> >> Signed-off-by: John Stultz <john.stultz@linaro.org> >> --- >> mm/vmscan.c | 26 ++++---------------------- >> 1 file changed, 4 insertions(+), 22 deletions(-) >> >> diff --git a/mm/vmscan.c b/mm/vmscan.c >> index 34f159a..07b0a8c 100644 >> --- a/mm/vmscan.c >> +++ b/mm/vmscan.c >> @@ -155,9 +155,8 @@ static unsigned long zone_reclaimable_pages(struct >> zone *zone) >> nr = zone_page_state(zone, NR_ACTIVE_FILE) + >> zone_page_state(zone, NR_INACTIVE_FILE); >> >> - if (get_nr_swap_pages() > 0) >> - nr += zone_page_state(zone, NR_ACTIVE_ANON) + >> - zone_page_state(zone, NR_INACTIVE_ANON); >> + nr += zone_page_state(zone, NR_ACTIVE_ANON) + >> + zone_page_state(zone, NR_INACTIVE_ANON); >> >> return nr; > > > Not all of the anonymous pages will be reclaimable. > > Is there some counter that keeps track of how many > volatile range pages there are in each zone?
So right, keeping statistics like NR_VOLATILE_PAGES (as well as possibly NR_PURGED_VOLATILE_PAGES), would likely help here.
>> @@ -2181,8 +2166,8 @@ static inline bool should_continue_reclaim(struct >> zone *zone, >> */ >> pages_for_compaction = (2UL << sc->order); >> inactive_lru_pages = zone_page_state(zone, NR_INACTIVE_FILE); >> - if (get_nr_swap_pages() > 0) >> - inactive_lru_pages += zone_page_state(zone, >> NR_INACTIVE_ANON); >> + inactive_lru_pages += zone_page_state(zone, NR_INACTIVE_ANON); >> + >> if (sc->nr_reclaimed < pages_for_compaction && >> inactive_lru_pages > pages_for_compaction) > > > Not sure this is a good idea, since the pages may not actually > be reclaimable, and the inactive list will continue to be > refilled indefinitely... > > If there was a counter of the number of volatile range pages > in a zone, this would be easier. > > Of course, the overhead of keeping such a counter might be > too high for what volatile ranges are designed for...
I started looking at something like this, but it runs into some complexity when we're keeping volatility as a flag in the vma rather then as a page state.
Also, even with a rough attempt at tracking of the number of volatile pages, it seemed naively plugging that in for NR_INACTIVE_ANON here was problematic, since we would scan for a shorter time, but but wouldn't necessarily find the volatile pages in that time, causing us not to always purge the volatile pages.
Part of me starts to wonder if a new LRU for volatile pages would be needed to really be efficient here, but then I worry the moving of the pages back and forth might be too expensive.
Thanks so much for the review and comments! -john
| |