[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <551C5744.3020408@redhat.com>
Date: Wed, 01 Apr 2015 16:38:28 -0400
From: Rik van Riel <riel@...hat.com>
To: "Wang, Yalin" <Yalin.Wang@...ymobile.com>,
"'Minchan Kim'" <minchan@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
Michal Hocko <mhocko@...e.cz>,
Johannes Weiner <hannes@...xchg.org>,
Mel Gorman <mgorman@...e.de>, Shaohua Li <shli@...nel.org>
Subject: Re: [PATCH 3/4] mm: move lazy free pages to inactive list
On 03/10/2015 10:14 PM, Wang, Yalin wrote:
>> -----Original Message-----
>> From: Minchan Kim [mailto:minchan@...nel.org]
>> Sent: Wednesday, March 11, 2015 9:21 AM
>> To: Andrew Morton
>> Cc: linux-kernel@...r.kernel.org; linux-mm@...ck.org; Michal Hocko;
>> Johannes Weiner; Mel Gorman; Rik van Riel; Shaohua Li; Wang, Yalin; Minchan
>> Kim
>> Subject: [PATCH 3/4] mm: move lazy free pages to inactive list
>>
>> MADV_FREE is hint that it's okay to discard pages if there is
>> memory pressure and we uses reclaimers(ie, kswapd and direct reclaim)
>> to free them so there is no worth to remain them in active anonymous LRU
>> so this patch moves them to inactive LRU list's head.
>>
>> This means that MADV_FREE-ed pages which were living on the inactive list
>> are reclaimed first because they are more likely to be cold rather than
>> recently active pages.
>>
>> A arguable issue for the approach would be whether we should put it to
>> head or tail in inactive list. I selected *head* because kernel cannot
>> make sure it's really cold or warm for every MADV_FREE usecase but
>> at least we know it's not *hot* so landing of inactive head would be
>> comprimise for various usecases.
>>
>> This is fixing a suboptimal behavior of MADV_FREE when pages living on
>> the active list will sit there for a long time even under memory
>> pressure while the inactive list is reclaimed heavily. This basically
>> breaks the whole purpose of using MADV_FREE to help the system to free
>> memory which is might not be used.
>>
>> Acked-by: Michal Hocko <mhocko@...e.cz>
>> Signed-off-by: Minchan Kim <minchan@...nel.org>
>> ---
>> include/linux/swap.h | 1 +
>> mm/madvise.c | 2 ++
>> mm/swap.c | 35 +++++++++++++++++++++++++++++++++++
>> 3 files changed, 38 insertions(+)
>>
>> diff --git a/include/linux/swap.h b/include/linux/swap.h
>> index cee108c..0428e4c 100644
>> --- a/include/linux/swap.h
>> +++ b/include/linux/swap.h
>> @@ -308,6 +308,7 @@ extern void lru_add_drain_cpu(int cpu);
>> extern void lru_add_drain_all(void);
>> extern void rotate_reclaimable_page(struct page *page);
>> extern void deactivate_file_page(struct page *page);
>> +extern void deactivate_page(struct page *page);
>> extern void swap_setup(void);
>>
>> extern void add_page_to_unevictable_list(struct page *page);
>> diff --git a/mm/madvise.c b/mm/madvise.c
>> index ebe692e..22e8f0c 100644
>> --- a/mm/madvise.c
>> +++ b/mm/madvise.c
>> @@ -340,6 +340,8 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned
>> long addr,
>> ptent = pte_mkold(ptent);
>> ptent = pte_mkclean(ptent);
>> set_pte_at(mm, addr, pte, ptent);
>> + if (PageActive(page))
>> + deactivate_page(page);
>> tlb_remove_tlb_entry(tlb, pte, addr);
>> }
>
> I think this place should be changed like this:
> + if (!page_referenced(page, false, NULL, NULL, NULL) && PageActive(page))
> + deactivate_page(page);
> Because we don't know if other processes are reference this page,
> If it is true, don't need deactivate this page.
We never clear the page and pte referenced bits on an active
page, that is only done when the page is moved to the inactive
list through LRU movement.
In other words, the page_referenced() check will return true
most of the time, even if the page was last referenced half
an hour ago (but there was no memory pressure).
Minchan's code looks correct.
The code may even want a ClearPageReferenced(page) in there...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists