memory reclaim more efficiently

PATCH In review Takenori Nagano 2 participants 3 messages Jun 23, 2008

Subsystems (3)

Memory management MGLRU MM reclaim

lore

Share & tools

lore

Takenori Nagano

author

2008-06-23 00:55 UTC #0 lore raw

PATCH 1/1 memory reclaim more efficiently

Hi,

Efficiency of memory reclaim is recently one of the hot topics. (LRU splitting, pageout throttling, etc...) I would like to contribute it and I made this patch.

In shrink_zone(), system can not return to user mode before it finishes to search LRU list. IMHO, it is very wasteful, since the user processes stay unnecessarily long time in shrink_zone() loop and application response time becomes relatively bad. This patch changes shrink_zone() that it finishes memory reclaim when it reclaims enough memory.

the conditions to end searching:

1. order of request page is 0
2. process is not kswapd.
3. satisfy the condition to return try_to_free_pages()

   # nr_reclaim > SWAP_CLUSTER_MAX

Signed-off-by Takenori Nagano <[email protected]>

Signed-off-by Keiichi Kii <[email protected]>

---

mm/vmscan.c +3 -0

diff -uprN linux-2.6.26-rc6.orig/mm/vmscan.c linux-2.6.26-rc6/mm/vmscan.c
@@ -1224,6 +1224,9 @@ static unsigned long shrink_zone(int pri
 			nr_reclaimed += shrink_inactive_list(nr_to_scan, zone,
 								sc);
 		}
+		if (nr_reclaimed > sc->swap_cluster_max && !sc->order
+						&& !current_is_kswapd())
+			break;
 	}
 
 	throttle_vm_writeout(sc->gfp_mask);

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

KOSAKI Motohiro

2008-06-23 01:48 UTC #1 lore raw

Hi nagano-san,

Quoted 6 lines

In shrink_zone(), system can not return to user mode before it finishes to search LRU list. IMHO, it is very wasteful, since the user processes stay unnecessarily long time in shrink_zone() loop and application response time becomes relatively bad. This patch changes shrink_zone() that it finishes memory reclaim when it reclaims enough memory.

Quoted 6 lines

the conditions to end searching:
1. order of request page is 0
2. process is not kswapd.
3. satisfy the condition to return try_to_free_pages()
   # nr_reclaim > SWAP_CLUSTER_MAX

I have 3 question.

1. Do you have any performance number?
2. I think this patch advocate many try_to_free_pages() called is better than one try_to_free_page waste long time. right?
and, why do you think so?
3. if this patch improve perfomance, I guess DEF_PRIORITY is
too small on your machine.
if DEF_PRIORITY is proportional to system memory, do your problem are solved?

Takenori Nagano

author

2008-06-23 04:54 UTC #2 lore raw

Quoted 6 lines · KOSAKI Motohiro

Quoted 6 lines
Hi nagano-san,
Quoted 4 lines
Quoted 4 lines
In shrink_zone(), system can not return to user mode before it finishes to search LRU list. IMHO, it is very wasteful, since the user processes stay unnecessarily long time in shrink_zone() loop and application response time becomes relatively bad. This patch changes shrink_zone() that it finishes

memory

Quoted 8 lines

Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
reclaim when it reclaims enough memory.
the conditions to end searching:
1. order of request page is 0
2. process is not kswapd.
3. satisfy the condition to return try_to_free_pages()
   # nr_reclaim > SWAP_CLUSTER_MAX

Hi Kosaki-san,

Quoted 3 lines

Quoted 3 lines
I have 3 question.
1. Do you have any performance number?

I tested some, but I don't collect data. :-(
I will test again and post results.

Quoted 3 lines

Quoted 3 lines
2. I think this patch advocate many try_to_free_pages() called is better than one try_to_free_page waste long time. right?
and, why do you think so?

I think user process is stopped long time on memory reclaim is not good. It is enough for user process to reclaim memory is needed. We have kswapd memory reclaim daemon. I think memory reclaim is kswapd's job.

Quoted 3 lines

Quoted 3 lines
3. if this patch improve perfomance, I guess DEF_PRIORITY is
too small on your machine.
if DEF_PRIORITY is proportional to system memory, do your problem are solved?

Your idea is so nice. :-)
IMHO, it is not perfect if reclaimable memory is not on front.

Thanks,
Takenori