lkml.org 
[lkml]   [2008]   [Jun]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Experimental][PATCH] putback_lru_page rework
> > > -		unlock = putback_lru_page(newpage);
> > > + putback_lru_page(newpage);
> > > } else
> > > newpage->mapping = NULL;
> >
> > originally move_to_lru() called in unmap_and_move().
> > unevictable infrastructure patch move to this point for
> > calling putback_lru_page() under page locked.
> >
> > So, your patch remove page locked dependency.
> > move to unmap_and_move() again is better.
> >
> > it become page lock holding time reducing.
> >
> ok, will look into again.
>

I agree with Kosaki-san.

And VM_BUG_ON(page_count(newpage) != 1) in unmap_and_move()
is not correct again, IMHO.
I got this BUG actually when testing this patch(with
migratin_entry_wait fix).

unmap_and_move()
move_to_new_page()
migrate_page()
remove_migration_ptes()
putback_lru_page() (*1)
:
if (!newpage->mapping) (*2)
VM_BUG_ON(page_count(newpage) != 1)

If a anonymous page(without mapping) is migrated successfully,
this page is moved back to lru by putback_lru_page()(*1),
and the page count becomes 1(pte only).

At the same time(between *1 and *2), if the process
that owns this page are freeing this page, the page count
becomes 0 and ->mapping becomes NULL by free_hot_cold_page(),
so this BUG is caused.

I've not seen this BUG on real HW yet(seen twice on fake-numa
hvm guest of Xen), but I think it can happen theoretically.


Thanks,
Daisuke Nishimura.


\
 
 \ /
  Last update: 2008-06-19 10:05    [W:0.075 / U:0.324 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site