lkml.org 
[lkml]   [2009]   [Nov]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCHv2 2/5] vmscan: Kill hibernation specific reclaim logic and unify it
    Date
    On Monday 02 November 2009, KOSAKI Motohiro wrote:
    > > > Then, This patch changed shrink_all_memory() to only the wrapper function of
    > > > do_try_to_free_pages(). it bring good reviewability and debuggability, and solve
    > > > above problems.
    > > >
    > > > side note: Reclaim logic unificication makes two good side effect.
    > > > - Fix recursive reclaim bug on shrink_all_memory().
    > > > it did forgot to use PF_MEMALLOC. it mean the system be able to stuck into deadlock.
    > > > - Now, shrink_all_memory() got lockdep awareness. it bring good debuggability.
    > >
    > > As I said previously, I don't really see a reason to keep shrink_all_memory().
    > >
    > > Do you think that removing it will result in performance degradation?
    >
    > Hmm...
    > Probably, I misunderstood your mention. I thought you suggested to kill
    > all hibernation specific reclaim code. I did. It's no performance degression.
    > (At least, I didn't observe)
    >
    > But, if you hope to kill shrink_all_memory() function itsef, the short answer is,
    > it's impossible.
    >
    > Current VM reclaim code need some preparetion to caller, and there are existing in
    > both alloc_pages_slowpath() and try_to_free_pages(). We can't omit its preparation.

    Well, my grepping for 'shrink_all_memory' throughout the entire kernel source
    code seems to indicate that hibernate_preallocate_memory() is the only current
    user of it. I may be wrong, but I doubt it, unless some new users have been
    added since 2.6.31.

    In case I'm not wrong, it should be safe to drop it from
    hibernate_preallocate_memory(), because it's there for performance reasons
    only. Now, since hibernate_preallocate_memory() appears to be the only user of
    it, it should be safe to drop it entirely.

    > Please see following shrink_all_memory() code. it's pretty small. it only have
    > few vmscan preparation. I don't think it is hard to maintainance.

    No, it's not, but I'm really not sure it's worth keeping.

    Thanks,
    Rafael


    > =====================================================
    > unsigned long shrink_all_memory(unsigned long nr_to_reclaim)
    > {
    > struct reclaim_state reclaim_state;
    > struct scan_control sc = {
    > .gfp_mask = GFP_HIGHUSER_MOVABLE,
    > .may_swap = 1,
    > .may_unmap = 1,
    > .may_writepage = 1,
    > .nr_to_reclaim = nr_to_reclaim,
    > .hibernation_mode = 1,
    > .swappiness = vm_swappiness,
    > .order = 0,
    > .isolate_pages = isolate_pages_global,
    > };
    > struct zonelist * zonelist = node_zonelist(numa_node_id(), sc.gfp_mask);
    > struct task_struct *p = current;
    > unsigned long nr_reclaimed;
    >
    > p->flags |= PF_MEMALLOC;
    > lockdep_set_current_reclaim_state(sc.gfp_mask);
    > reclaim_state.reclaimed_slab = 0;
    > p->reclaim_state = &reclaim_state;
    >
    > nr_reclaimed = do_try_to_free_pages(zonelist, &sc);
    >
    > p->reclaim_state = NULL;
    > lockdep_clear_current_reclaim_state();
    > p->flags &= ~PF_MEMALLOC;
    >
    > return nr_reclaimed;
    > }


    \
     
     \ /
      Last update: 2009-11-02 20:05    [W:0.025 / U:2.244 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site