[RFC][PATCH] a bit improvement of ZONE_DMA page reclaim

[RFC][PATCH] a bit improvement of ZONE_DMA page reclaim

[KOSAKI Motohiro]

Hi

on X86, ZONE_DMA is very very small.
It is often no used at all. 

Unfortunately, 
when NR_ACTIVE==0, NR_INACTIVE==0, shrink_zone() try to reclaim 1 page.
because

    zone->nr_scan_active +=
        (zone_page_state(zone, NR_ACTIVE) >> priority) + 1;
                                                        ^^^^^

it cause unnecessary spent cpu time.

In addition, to a bad thing
when NR_ACTIVE==0 and NR_INACTIVE==0, zone_is_near_oom always true.
bacause 0 >= 0+0 is true.

the effect of this strange behavior is very small.
but it confuse to the VM newbie developer (= me) ;-)



this patch against: 2.6.24-rc6-mm1

Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
---
 mm/vmscan.c |   21 ++++++++++++++++-----
 1 file changed, 16 insertions(+), 5 deletions(-)

Index: b/mm/vmscan.c
===================================================================
--- a/mm/vmscan.c       2008-01-18 14:18:27.000000000 +0900
+++ b/mm/vmscan.c       2008-01-18 14:49:06.000000000 +0900
@@ -948,7 +948,7 @@ static inline void note_zone_scanning_pr

 static inline int zone_is_near_oom(struct zone *zone)
 {
-       return zone->pages_scanned >= (zone_page_state(zone, NR_ACTIVE)
+       return zone->pages_scanned > (zone_page_state(zone, NR_ACTIVE)
                                + zone_page_state(zone, NR_INACTIVE))*3;
 }

@@ -1214,18 +1214,29 @@ static unsigned long shrink_zone(int pri
        unsigned long nr_inactive;
        unsigned long nr_to_scan;
        unsigned long nr_reclaimed = 0;
+       unsigned long tmp;
+       unsigned long zone_active;
+       unsigned long zone_inactive;

        if (scan_global_lru(sc)) {
                /*
                 * Add one to nr_to_scan just to make sure that the kernel
                 * will slowly sift through the active list.
                 */
-               zone->nr_scan_active +=
-                       (zone_page_state(zone, NR_ACTIVE) >> priority) + 1;
+               zone_active = zone_page_state(zone, NR_ACTIVE);
+               tmp = (zone_active >> priority) + 1;
+               if (unlikely(tmp > zone_active))
+                       tmp = zone_active;
+               zone->nr_scan_active += tmp;
                nr_active = zone->nr_scan_active;
-               zone->nr_scan_inactive +=
-                       (zone_page_state(zone, NR_INACTIVE) >> priority) + 1;
+
+               zone_inactive = zone_page_state(zone, NR_INACTIVE);
+               tmp = (zone_inactive >> priority) + 1;
+               if (unlikely(tmp > zone_inactive))
+                       tmp = zone_inactive;
+               zone->nr_scan_inactive += tmp;
                nr_inactive = zone->nr_scan_inactive;
+
                if (nr_inactive >= sc->swap_cluster_max)
                        zone->nr_scan_inactive = 0;
                else



--
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-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [RFC][PATCH] a bit improvement of ZONE_DMA page reclaim

[Andrew Morton]

On Fri, 18 Jan 2008 15:34:33 +0900 KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote:

> Hi
> 
> on X86, ZONE_DMA is very very small.
> It is often no used at all. 

In that case page-reclaim is supposed to set all_unreclaimable and
basically ignores the zone altogether until it looks like something might
have changed.

Is that code not working?  (quite possible).


--
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-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [RFC][PATCH] a bit improvement of ZONE_DMA page reclaim

[KOSAKI Motohiro]

Hi Andrew

> > on X86, ZONE_DMA is very very small.
> > It is often no used at all. 
> 
> In that case page-reclaim is supposed to set all_unreclaimable and
> basically ignores the zone altogether until it looks like something might
> have changed.
> 
> Is that code not working?  (quite possible).

please insert blow debug printk and dd if=bigfile of=/dev/null.
you see "near_oom(DMA) 0 0 0" messages :)

at least, I can reproduce it on my machine.

my machine
	CPU: x86_64 1.86GHz x2
	memory: 6G

- kosaki


Index: b/mm/vmscan.c
===================================================================
--- a/mm/vmscan.c       2008-01-18 14:49:06.000000000 +0900
+++ b/mm/vmscan.c       2008-01-18 14:50:21.000000000 +0900
@@ -966,8 +966,14 @@ static int calc_reclaim_mapped(struct sc
        int reclaim_mapped = 0;
        int prev_priority;

-       if (scan_global_lru(sc) && zone_is_near_oom(zone))
+       if (scan_global_lru(sc) && zone_is_near_oom(zone)) {
+               printk("near_oom(%s) %ld %ld %ld\n",
+                      zone->name,
+                      zone->pages_scanned,
+                      zone_page_state(zone, NR_ACTIVE),
+                      zone_page_state(zone, NR_INACTIVE));
                return 1;
+       }
        /*
         * `distress' is a measure of how much trouble we're having
         * reclaiming pages.  0 -> no problems.  100 -> great trouble.

--
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-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [RFC][PATCH] a bit improvement of ZONE_DMA page reclaim

[KOSAKI Motohiro]

Hi Andrew,

> > > on X86, ZONE_DMA is very very small.
> > > It is often no used at all. 
> > 
> > In that case page-reclaim is supposed to set all_unreclaimable and
> > basically ignores the zone altogether until it looks like something might
> > have changed.
> > 
> > Is that code not working?  (quite possible).
> 
> please insert blow debug printk and dd if=bigfile of=/dev/null.
> you see "near_oom(DMA) 0 0 0" messages :)

sorry, my last mail is not enough description.
It is not so useful at solo use. 
As you say, If long time passes all_unreclaimable turn on and 
incorrect shrink list become no happned.

but, my mem_notify patch very dislike incorrect shrink ;-)

result as, I don't hope quick merge.
and I will merge to my mem_notify patch series.

Thanks.


- kosaki


--
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-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>