Re: PF_MEMALLOC in 2.6

[Nick Piggin]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/