Messages in this thread | | | Date | Fri, 20 Aug 2004 19:06:23 +1000 | From | Nick Piggin <> | Subject | Re: PF_MEMALLOC in 2.6 |
| |
Oliver Neukum wrote: > Am Freitag, 20. August 2004 10:06 schrieb Nick Piggin: > >>>>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? > > > The write request will have to wait. Storage cannot do concurrent IO. > But all memory allocated in the read request will be GFP_NOIO or > GFP_ATOMIC so the conclusion of the memory allocation should not > wait for IO. Either it fails and we report that to the SCSI layer or it > is completed and the write serviced in turn. > At least that's the intent. >
In that case, having the SCSI layer pass down the flag may be a viable option.
Just FYI, non atomic allocations need to be __GFP_NORETRY otherwise they won't fail (unless order >= 3). I suspect this detail is fairly important. - 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/
| |