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 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/

\
 
 \ /
  Last update: 2005-03-22 14:05    [W:0.113 / U:29.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site