lkml.org 
[lkml]   [2004]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: PF_MEMALLOC in 2.6
    Oliver Neukum wrote:
    > Am Freitag, 20. August 2004 04:37 schrieb Nick Piggin:
    >
    >>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.
    >
    >
    > Then the SCSI layer should pass down the flag.
    >

    It would be ideal from the memory allocator's point of view to do it
    on a per-request basis like that.

    When the rubber hits the road, I think it is probably going to be very
    troublesome to do it right that way. For example, what happens when
    your usb-thingy-thread blocks on a memory allocation while handling a
    read request, then the system gets low on memory and someone tries to
    free some by submitting a write request to the USB device?

    I don't know anything about how the usb thread works so I'm not sure.

    The mempool model seems to work well for requests in the block layer -
    making a completely uneducated guess I'd say that could be a good
    option to investigate.
    -
    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 14:05    [W:2.639 / U:0.072 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site