lkml.org 
[lkml]   [2010]   [Jun]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 05/12] vmscan: kill prev_priority completely
    On Mon, 14 Jun 2010 12:17:46 +0100
    Mel Gorman <mel@csn.ul.ie> wrote:

    > From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    >
    > Since 2.6.28 zone->prev_priority is unused. Then it can be removed
    > safely. It reduce stack usage slightly.
    >
    > Now I have to say that I'm sorry. 2 years ago, I thought prev_priority
    > can be integrate again, it's useful. but four (or more) times trying
    > haven't got good performance number. Thus I give up such approach.

    This would have been badder in earlier days when we were using the
    scanning priority to decide when to start unmapping pte-mapped pages -
    page reclaim would have been recirculating large blobs of mapped pages
    around the LRU until the priority had built to the level where we
    started to unmap them.

    However that priority-based decision got removed and right now I don't
    recall what it got replaced with. Aren't we now unmapping pages way
    too early and suffering an increased major&minor fault rate? Worried.


    Things which are still broken after we broke prev_priority:

    - If page reclaim is having a lot of trouble, prev_priority would
    have permitted do_try_to_free_pages() to call disable_swap_token()
    earlier on. As things presently stand, we'll do a lot of
    thrash-detection stuff before (presumably correctly) dropping the
    swap token.

    So. What's up with that? I don't even remember _why_ we disable
    the swap token once the scanning priority gets severe and the code
    comments there are risible. And why do we wait until priority==0
    rather than priority==1?

    - Busted prev_priority means that lumpy reclaim will act oddly.
    Every time someone goes into do some recalim, they'll start out not
    doing lumpy reclaim. Then, after a while, they'll get a clue and
    will start doing the lumpy thing. Then they return from reclaim and
    the next recalim caller will again forget that he should have done
    lumpy reclaim.

    I dunno what the effects of this are in the real world, but it
    seems dumb.

    And one has to wonder: if we're making these incorrect decisions based
    upon a bogus view of the current scanning difficulty, why are these
    various priority-based thresholding heuristics even in there? Are they
    doing anything useful?

    So.. either we have a load of useless-crap-and-cruft in there which
    should be lopped out, or we don't have a load of useless-crap-and-cruft
    in there, and we should fix prev_priority.

    > Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    > Reviewed-by: Johannes Weiner <hannes@cmpxchg.org>
    > Signed-off-by: Mel Gorman <mel@csn.ul.ie>
    > ---
    > include/linux/mmzone.h | 15 ------------
    > mm/page_alloc.c | 2 -
    > mm/vmscan.c | 57 ------------------------------------------------
    > mm/vmstat.c | 2 -

    The patch forgot to remove mem_cgroup_get_reclaim_priority() and friends.


    \
     
     \ /
      Last update: 2010-06-17 01:41    [W:0.031 / U:0.620 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site