Techwizz/kernel-fxtec-pro1x
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

mm: unlockless reclaim

Browse source 
unlock_page is fairly expensive.  It can be avoided in page reclaim
success path.  By definition if we have any other references to the page
it would be a bug anyway.

Signed-off-by: Nick Piggin <npiggin@suse.de>
Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This commit is contained in:
Nick Piggin 2008-10-18 20:26:58 -07:00 committed by Linus Torvalds
parent f45840b5c1
commit a978d6f521
1 changed files with 8 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

9
mm/vmscan.c
View file

@ -732,7 +732,14 @@ static unsigned long shrink_page_list(struct list_head *page_list,
if (!mapping || !__remove_mapping(mapping, page)) if (!mapping || !__remove_mapping(mapping, page))
goto keep_locked; goto keep_locked;
unlock_page(page); /*
* At this point, we have no other references and there is
* no way to pick any more up (removed from LRU, removed
* from pagecache). Can use non-atomic bitops now (and
* we obviously don't have to worry about waking up a process
* waiting on the page lock, because there are no references.
*/
__clear_page_locked(page);
free_it: free_it:
nr_reclaimed++; nr_reclaimed++;
if (!pagevec_add(&freed_pvec, page)) { if (!pagevec_add(&freed_pvec, page)) {