[lkml]   [2001]   [Sep]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Feedback on preemptible kernel patch
    On September 10, 2001 07:09 am, Robert Love wrote:
    > On Sun, 2001-09-09 at 23:24, Daniel Phillips wrote:
    > > This may not be your fault. It's a GFP_NOFS recursive allocation - this
    > > comes either from grow_buffers or ReiserFS, probably the former. In
    > > either case, it means we ran completely out of free pages, even though
    > > the caller is willing to wait. Hmm. It smells like a loophole in vm
    > > scanning.
    > I am not a VM hacker -- can you tell me where to start? what do you
    > suspect it is?
    > If the user stops seeing the error with preemption disabled, is your
    > theory nulled, or does that just mean the problem is agitated by
    > preemption?
    > I don't think Arjan was using ReiserFS, so its from grow_buffers...
    > I appreciate your help.

    The first thing to check is whether memory is really exhausted at the
    time the errors are logged (cat /proc/meminfo). Then you want to see
    which paths in __alloc_pages could possibly allow this PF_MEMALLOC +
    GFP_WAIT allocation request to drop all the way through without being
    serviced. Sorry, I haven't had time to do that and won't for a few
    days. Even if you triggered it, it is probably a hole in the scan
    logic. We have __GFP_WAIT, so it should wait.

    Here's a hint, look very critically at this part of page_alloc.c:

    455 /*
    456 * Fail in case no progress was made and the
    457 * allocation may not be able to block on IO.
    458 */
    459 return NULL;

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:03    [W:0.022 / U:0.824 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site