lkml.org 
[lkml]   [2001]   [Sep]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    SubjectRe: __alloc_pages: 0-order allocation failed still in -pre12
    On Wed, Sep 19, 2001 at 07:36:49PM -0700, Shane Wegner wrote:
    > On Wed, Sep 19, 2001 at 07:31:28PM -0700, Shane Wegner wrote:
    > > On Thu, Sep 20, 2001 at 12:45:43AM +0200, Andrea Arcangeli wrote:
    > > > On Wed, Sep 19, 2001 at 03:34:41PM -0700, Shane Wegner wrote:
    > > > >
    > > > > __alloc_pages: 0-order allocation failed (gfp=0x20/0) from
    > > > > c012e052
    > > > > __alloc_pages: 0-order allocation failed (gfp=0x20/0) from
    > > > > c012e052
    > > > > __alloc_pages: 0-order allocation failed (gfp=0x20/0) from
    > > > > c012e052
    > > >
    > > > yes, please try this fix and let me know if it helps:
    > >
    > > After some stress testing, the fix does appear to fix the
    > > error.
    >
    > Hi,
    >
    > Well just after I sent the email, it came up again.
    >
    >
    > Sep 19 19:31:52 continuum kernel: __alloc_pages: 0-order
    > allocation failed (gfp=0x20/0) from c012e052
    > Sep 19 19:33:51 continuum kernel: __alloc_pages: 0-order
    > allocation failed (gfp=0x20/0) from c012e052

    did it happen as frequently/easily as before or did you need to stress
    it much harder? And I'm also curious what happens if we simply lower the
    watemark (possibly it was too high). Anyways the other patch is a good
    idea to apply anyways.

    So can now try the below new one?

    --- 2.4.10pre11aa1/mm/page_alloc.c.~1~ Thu Sep 20 00:36:11 2001
    +++ 2.4.10pre11aa1/mm/page_alloc.c Thu Sep 20 04:45:44 2001
    @@ -346,7 +346,7 @@
    if (!z)
    break;

    - if (zone_free_pages(z, order) > (gfp_mask & __GFP_HIGH ? z->pages_min / 2 : z->pages_min)) {
    + if (zone_free_pages(z, order) > (gfp_mask & __GFP_HIGH ? z->pages_min / 4 : z->pages_min)) {
    page = rmqueue(z, order);
    if (page)
    return page;

    the fact is, kswapd is the only entity meant to shrink the caches for
    the atomic pages, it exactly knows what are the zones that needs to be
    balanced and we have a min-min/2 of pages of GAP that must be refilled
    in time. It just seems kswapd doesn't cope with the frequency of the
    allocations sometime, this may be ok but maybe we must find a way to
    more aggressively free memory for the atomic allocations or it could
    simply mean that the watermark GAP was too small as Marcelo just
    suggested previously.

    Can you also resolve "c012e052" so we know who's allocating those pages
    just in case?

    Andrea
    -
    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: 2005-03-22 13:03    [W:2.782 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site