Messages in this thread | | | Date | Fri, 20 Aug 2004 18:06:41 +1000 | From | Nick Piggin <> | Subject | Re: 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/
| |