lkml.org 
[lkml]   [2006]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    From
    Subject[PATCH 11/34] mm: page-replace-should_reclaim_mapped.patch
    Date

    From: Peter Zijlstra <a.p.zijlstra@chello.nl>

    Move the reclaim_mapped code over to its own function so that other
    reclaim policies can make use of it.

    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Signed-off-by: Marcelo Tosatti <marcelo.tosatti@cyclades.com>

    ---

    mm/vmscan.c | 86 ++++++++++++++++++++++++++++++++----------------------------
    1 file changed, 46 insertions(+), 40 deletions(-)

    Index: linux-2.6/mm/vmscan.c
    ===================================================================
    --- linux-2.6.orig/mm/vmscan.c 2006-03-13 20:37:32.000000000 +0100
    +++ linux-2.6/mm/vmscan.c 2006-03-13 20:37:33.000000000 +0100
    @@ -978,6 +978,50 @@ done:
    pagevec_release(&pvec);
    }

    +int should_reclaim_mapped(struct zone *zone, struct scan_control *sc)
    +{
    + long mapped_ratio;
    + long distress;
    + long swap_tendency;
    +
    + /*
    + * `distress' is a measure of how much trouble we're having
    + * reclaiming pages. 0 -> no problems. 100 -> great trouble.
    + */
    + distress = 100 >> zone->prev_priority;
    +
    + /*
    + * The point of this algorithm is to decide when to start
    + * reclaiming mapped memory instead of just pagecache. Work out
    + * how much memory
    + * is mapped.
    + */
    + mapped_ratio = (sc->nr_mapped * 100) / total_memory;
    +
    + /*
    + * Now decide how much we really want to unmap some pages. The
    + * mapped ratio is downgraded - just because there's a lot of
    + * mapped memory doesn't necessarily mean that page reclaim
    + * isn't succeeding.
    + *
    + * The distress ratio is important - we don't want to start
    + * going oom.
    + *
    + * A 100% value of vm_swappiness overrides this algorithm
    + * altogether.
    + */
    + swap_tendency = mapped_ratio / 2 + distress + vm_swappiness;
    +
    + /*
    + * Now use this metric to decide whether to start moving mapped
    + * memory onto the inactive list.
    + */
    + if (swap_tendency >= 100)
    + return 1;
    +
    + return 0;
    +}
    +
    /*
    * This moves pages from the active list to the inactive list.
    *
    @@ -1009,46 +1053,8 @@ refill_inactive_zone(struct zone *zone,
    struct pagevec pvec;
    int reclaim_mapped = 0;

    - if (unlikely(sc->may_swap)) {
    - long mapped_ratio;
    - long distress;
    - long swap_tendency;
    -
    - /*
    - * `distress' is a measure of how much trouble we're having
    - * reclaiming pages. 0 -> no problems. 100 -> great trouble.
    - */
    - distress = 100 >> zone->prev_priority;
    -
    - /*
    - * The point of this algorithm is to decide when to start
    - * reclaiming mapped memory instead of just pagecache. Work out
    - * how much memory
    - * is mapped.
    - */
    - mapped_ratio = (sc->nr_mapped * 100) / total_memory;
    -
    - /*
    - * Now decide how much we really want to unmap some pages. The
    - * mapped ratio is downgraded - just because there's a lot of
    - * mapped memory doesn't necessarily mean that page reclaim
    - * isn't succeeding.
    - *
    - * The distress ratio is important - we don't want to start
    - * going oom.
    - *
    - * A 100% value of vm_swappiness overrides this algorithm
    - * altogether.
    - */
    - swap_tendency = mapped_ratio / 2 + distress + vm_swappiness;
    -
    - /*
    - * Now use this metric to decide whether to start moving mapped
    - * memory onto the inactive list.
    - */
    - if (swap_tendency >= 100)
    - reclaim_mapped = 1;
    - }
    + if (unlikely(sc->may_swap))
    + reclaim_mapped = should_reclaim_mapped(zone, sc);

    page_replace_add_drain();
    spin_lock_irq(&zone->lru_lock);
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/
    \
     
     \ /
      Last update: 2006-03-22 23:36    [W:4.406 / U:0.468 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site