lkml.org 
[lkml]   [2011]   [May]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: Kernel falls apart under light memory pressure (i.e. linking vmlinux)
    From
    On Tue, May 17, 2011 at 2:52 PM, Wu Fengguang <fengguang.wu@intel.com> wrote:
    > On Mon, May 16, 2011 at 07:40:42AM +0900, Minchan Kim wrote:
    >> On Mon, May 16, 2011 at 12:27 AM, Wu Fengguang <fengguang.wu@intel.com> wrote:
    >> > On Sun, May 15, 2011 at 09:37:58AM +0800, Minchan Kim wrote:
    >> >> On Sun, May 15, 2011 at 2:43 AM, Andi Kleen <andi@firstfloor.org> wrote:
    >> >> > Copying back linux-mm.
    >> >> >
    >> >> >> Recently, we added following patch.
    >> >> >> https://lkml.org/lkml/2011/4/26/129
    >> >> >> If it's a culprit, the patch should solve the problem.
    >> >> >
    >> >> > It would be probably better to not do the allocations at all under
    >> >> > memory pressure.  Even if the RA allocation doesn't go into reclaim
    >> >>
    >> >> Fair enough.
    >> >> I think we can do it easily now.
    >> >> If page_cache_alloc_readahead(ie, GFP_NORETRY) is fail, we can adjust
    >> >> RA window size or turn off a while. The point is that we can use the
    >> >> fail of __do_page_cache_readahead as sign of memory pressure.
    >> >> Wu, What do you think?
    >> >
    >> > No, disabling readahead can hardly help.
    >>
    >> I don't mean we have to disable RA.
    >> As I said, the point is that we can use __GFP_NORETRY alloc fail as
    >> _sign_ of memory pressure.
    >
    > I see.
    >
    >> >
    >> > The sequential readahead memory consumption can be estimated by
    >> >
    >> >                2 * (number of concurrent read streams) * (readahead window size)
    >> >
    >> > And you can double that when there are two level of readaheads.
    >> >
    >> > Since there are hardly any concurrent read streams in Andy's case,
    >> > the readahead memory consumption will be ignorable.
    >> >
    >> > Typically readahead thrashing will happen long before excessive
    >> > GFP_NORETRY failures, so the reasonable solutions are to
    >>
    >> If it is, RA thrashing could be better sign than failure of __GFP_NORETRY.
    >> If we can do it easily, I don't object it. :)
    >
    > Yeah, the RA thrashing is much better sign because it not only happens
    > long before normal __GFP_NORETRY failures, but also offers hint on how
    > tight memory pressure it is. We can then shrink the readahead window
    > adaptively to the available page cache memory :)
    >
    >> >
    >> > - shrink readahead window on readahead thrashing
    >> >  (current readahead heuristic can somehow do this, and I have patches
    >> >  to further improve it)
    >>
    >> Good to hear. :)
    >> I don't want RA steals high order page in memory pressure.
    >
    > More often than not it won't be RA's fault :)  When you see RA page
    > allocations stealing high order pages, it may actually be reflecting
    > some more general order-0 steal order-N problem..

    Agree.
    As I said to Andy, it's a general problem but RA has a possibility to
    reduce it while others don't have a any solution. :(

    --
    Kind regards,
    Minchan Kim
    --
    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: 2011-05-17 08:29    [W:0.026 / U:29.968 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site