[patch] mm-deactivate-fix-1

[patch] mm-deactivate-fix-1

[Zlatko Calusic]

I have noticed that in deactivate_page_nolock() function pages get
unconditionally moved from the active to the inact_dirty list. Even if
it is really easy with additional check to put them straight to the
inact_clean list if they're freeable. That keeps the list statistics
more accurate and in the end should result in a little bit less CPU
cycles burned (only one list transition, less locking). As a bonus,
the comment above the function is now correct. :)

I have tested the patch thoroughly and couldn't find any problems with
it. It should be really safe as reclaim_page() already carefully
checks pages before freeing.

Comments?


Index: 0.19/mm/swap.c
--- 0.19/mm/swap.c Sat, 06 Jan 2001 01:48:21 +0100 zcalusic (linux24/j/17_swap.c 1.1 644)
+++ 0.19(w)/mm/swap.c Sun, 14 Jan 2001 14:05:49 +0100 zcalusic (linux24/j/17_swap.c 1.1 644)
@@ -172,7 +172,6 @@
 	 * Besides, as long as we don't move unfreeable pages to the
 	 * inactive_clean list it doesn't need to be perfect...
 	 */
-	int maxcount = (page->buffers ? 3 : 2);
 	page->age = 0;
 	ClearPageReferenced(page);
 
@@ -180,11 +179,19 @@
 	 * Don't touch it if it's not on the active list.
 	 * (some pages aren't on any list at all)
 	 */
-	if (PageActive(page) && page_count(page) <= maxcount && !page_ramdisk(page)) {
-		del_page_from_active_list(page);
+	if (!PageActive(page)
+	    || page_count(page) > (page->buffers ? 3 : 2)
+	    || page_ramdisk(page))
+		return;
+
+	del_page_from_active_list(page);
+
+	if (page->mapping && !page->buffers && !PageDirty(page)) {
+		add_page_to_inactive_clean_list(page);
+	} else {
 		add_page_to_inactive_dirty_list(page);
 	}
-}	
+}
 
 void deactivate_page(struct page * page)
 {

-- 
Zlatko
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: [patch] mm-deactivate-fix-1

[Marcelo Tosatti]

On 14 Jan 2001, Zlatko Calusic wrote:

> I have noticed that in deactivate_page_nolock() function pages get
> unconditionally moved from the active to the inact_dirty list. Even if
> it is really easy with additional check to put them straight to the
> inact_clean list if they're freeable. That keeps the list statistics
> more accurate and in the end should result in a little bit less CPU
> cycles burned (only one list transition, less locking). As a bonus,
> the comment above the function is now correct. :)
> 
> I have tested the patch thoroughly and couldn't find any problems with
> it. It should be really safe as reclaim_page() already carefully
> checks pages before freeing.
> 
> Comments?

We want to move all deactivated pages to the inactive dirty list to get
FIFO behaviour while reclaiming them.



--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: [patch] mm-deactivate-fix-1

[Zlatko Calusic]

Marcelo Tosatti <marcelo@conectiva.com.br> writes:

> On 14 Jan 2001, Zlatko Calusic wrote:
> 
> > I have noticed that in deactivate_page_nolock() function pages get
> > unconditionally moved from the active to the inact_dirty list. Even if
> > it is really easy with additional check to put them straight to the
> > inact_clean list if they're freeable. That keeps the list statistics
> > more accurate and in the end should result in a little bit less CPU
> > cycles burned (only one list transition, less locking). As a bonus,
> > the comment above the function is now correct. :)
> > 
> > I have tested the patch thoroughly and couldn't find any problems with
> > it. It should be really safe as reclaim_page() already carefully
> > checks pages before freeing.
> > 
> > Comments?
> 
> We want to move all deactivated pages to the inactive dirty list to get
> FIFO behaviour while reclaiming them.
> 

Ah, I see. Then your answer should be put above the function as a
comment. To help other souls digging around that code (like I'm
doing). :)
-- 
Zlatko
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/