[lkml]   [2004]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: PF_MEMALLOC in 2.6
    Oliver Neukum wrote:
    > Am Donnerstag, 19. August 2004 14:41 schrieb Hugh Dickins:
    >>Fine for it to dip into those reserves when acting on behalf of something
    >>already PF_MEMALLOC (i.e. try_to_free_pages itself), but not fine for it
    >>to do so as a matter of course e.g. worst case, doing readahead could
    >>easily exhaust reserves. Or, is this thread only used for writing?
    >>that wouldn't be so bad if so.
    > All IO going to the actual disk uses the thread. However we usually
    > don't want to fail IO request due to low memory.

    I'm with Hugh on this one. You only want to be PF_MEMALLOC when
    you are in the process of cleaning some memory so it can be freed.
    (Perhaps it would be more logical if it were called PF_MEMFREE, and
    set in mm/vmscan.c, however the end result is the same)

    So if this thing allocates memory on behalf of a read request, then
    it is basically a bug. In practice you could probably get away with
    servicing all writes with PF_MEMALLOC, however that could still lead
    to situations where it consumes all your low memory on behalf of
    highmem IO (though perhaps this won't deadlock if that memory is
    going to be released as a matter of course?)

    Another thing, having it always use PF_MEMALLOC means it can easily
    wipe out the GFP_ATOMIC reserve.

    So I'd say try to find a way to only use PF_MEMALLOC on behalf of
    a PF_MEMALLOC thread or use a mempool or something.
    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 14:05    [W:0.021 / U:92.452 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site