lkml.org 
[lkml]   [2009]   [Oct]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH 1/5] page allocator: Always wake kswapd when restarting an allocation attempt after direct reclaim failed
    Date
    > On Mon, 26 Oct 2009, KOSAKI Motohiro wrote:
    >
    > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
    > > index bf72055..5a27896 100644
    > > --- a/mm/page_alloc.c
    > > +++ b/mm/page_alloc.c
    > > @@ -1899,6 +1899,12 @@ rebalance:
    > > if (should_alloc_retry(gfp_mask, order, pages_reclaimed)) {
    > > /* Wait for some write requests to complete then retry */
    > > congestion_wait(BLK_RW_ASYNC, HZ/50);
    > > +
    > > + /*
    > > + * While we wait congestion wait, Amount of free memory can
    > > + * be changed dramatically. Thus, we kick kswapd again.
    > > + */
    > > + wake_all_kswapd(order, zonelist, high_zoneidx);
    > > goto rebalance;
    > > }
    > >
    >
    > We're blocking to finish writeback of the directly reclaimed memory, why
    > do we need to wake kswapd afterwards?

    the same reason of "goto restart" case. that's my intention.
    if following scenario occur, it is equivalent that we didn't call wake_all_kswapd().

    1. call congestion_wait()
    2. kswapd reclaimed lots memory and sleep
    3. another task consume lots memory
    4. wakeup from congestion_wait()

    IOW, if we falled into __alloc_pages_slowpath(), we naturally expect
    next page_alloc() don't fall into slowpath. however if kswapd end to
    its work too early, this assumption isn't true.

    Is this too pessimistic assumption?







    \
     
     \ /
      Last update: 2009-10-27 03:45    [W:0.043 / U:88.200 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site