Re: [PATCH] mm: vmscan: recompute page status when putting back

From: Hillf Danton
Date: Tue Jan 10 2012 - 09:32:36 EST


On Tue, Jan 10, 2012 at 11:44 AM, KAMEZAWA Hiroyuki
<kamezawa.hiroyu@xxxxxxxxxxxxxx> wrote:
> On Fri, 6 Jan 2012 22:07:29 +0800
> Hillf Danton <dhillf@xxxxxxxxx> wrote:
>
>> If unlikely the given page is isolated from lru list again, its status is
>> recomputed before putting back to lru list, since the comment says page's
>> status can change while we move it among lru.
>>
>>
>> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx>
>> Cc: David Rientjes <rientjes@xxxxxxxxxx>
>> Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
>> Signed-off-by: Hillf Danton <dhillf@xxxxxxxxx>
>> ---
>>
>> --- a/mm/vmscan.c   Thu Dec 29 20:20:16 2011
>> +++ b/mm/vmscan.c   Fri Jan Â6 21:31:56 2012
>> @@ -633,12 +633,14 @@ int remove_mapping(struct address_space
>> Âvoid putback_lru_page(struct page *page)
>> Â{
>> Â Â Â int lru;
>> - Â Â int active = !!TestClearPageActive(page);
>> - Â Â int was_unevictable = PageUnevictable(page);
>> + Â Â int active;
>> + Â Â int was_unevictable;
>>
>> Â Â Â VM_BUG_ON(PageLRU(page));
>>
>> Âredo:
>> + Â Â active = !!TestClearPageActive(page);
>> + Â Â was_unevictable = PageUnevictable(page);
>> Â Â Â ClearPageUnevictable(page);
>>
>> Â Â Â if (page_evictable(page, NULL)) {
>
> Hm. Do you handle this case ?
> ==
> Â Â Â Â/*
> Â Â Â Â * page's status can change while we move it among lru. If an evictable
> Â Â Â Â * page is on unevictable list, it never be freed. To avoid that,
> Â Â Â Â * check after we added it to the list, again.
> Â Â Â Â */
> Â Â Â Âif (lru == LRU_UNEVICTABLE && page_evictable(page, NULL)) {
> Â Â Â Â Â Â Â Âif (!isolate_lru_page(page)) {
> Â Â Â Â Â Â Â Â Â Â Â Âput_page(page);
> Â Â Â Â Â Â Â Â Â Â Â Âgoto redo;
> Â Â Â Â Â Â Â Â}
> ==
>
> Ok, let's start from "was_unevictable"
>
> "was_unevicatable" is used for this
> ==
> Âif (was_unevictable && lru != LRU_UNEVICTABLE)
> Â Â Â Â Â Â Â Âcount_vm_event(UNEVICTABLE_PGRESCUED);
> ==
> This is for checking that the page turned out to be evictable while we put it
> into LRU. Assume the 'redo' case, the page's state chages from UNEVICTABLE to
> ACTIVE_ANON (for example)
>
> Â1. at start of function: Page was Unevictable, was_unevictable=true
> Â2. lru = LRU_UNEVICTABLE
> Â3, add the page to LRU.
> Â4. check page_evictable(),..... it returns 'true'.
> Â5. isoalte the page again and goto redo.
> Â6. lru = LRU_ACTIVE_ANON
> Â7. add the page to LRU.
> Â8. was_unevictable==true, then, count_vm_event(UNEVICTABLE_PGRESCUED);
>
> Your patch overwrites was_unevictable between 5. and 6., then,
> corrupts this event counting.
>
> about "active" flag.
>
> PageActive() flag will be set in lru_cache_add_lru() and
> there will be no inconsistency between page->flags and LRU.
> And, in what case the changes in 'active' will be problematic ?
>
Hi Kame

Thanks for reviewing my work.

With focus on the case that redo occurs, the patch was prepared based on the
assumption that any isolated page could be processed by the function.

If redo does occur, though unlikely, there are two rounds of isolation+putback
or more for the given page. As shown by my workout of page status, difference
exists in the two cases.

==============================================================
without redo with redo
==============================================================
active true 50% true
false 50% false 100%
==============================================================
was_unevictable true 50% true 100%
false 50% false
==============================================================

And the case with redo could be covered by the case without redo, so there is
no corruption of VM events.

Hillf
--
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/