consistent_free re-revisited

[Benjamin Herrenschmidt]

>> I tend to hate anything that relies on in_interrupt() as they
>> are other contexts that will have in_interrupt() cleared but still
>> have the same limitations. Typically, anything on the VM path must
>> do either GFP_ATOMIC or GFP_NOIO allocations, wether it's running
>> at interrupt time or not.
>
>The problem is that the atomic pool is limited, iirc.

Well, ATOMIC can fail, sure, but if you do GFP_KERNEL within a
VM code path, then be prepared for deadlocks.

A driver that would need such allocations during it's request
handling path would suck anyway and should pre-allocate ;) But
if this is the case, then it must be able to say that it wants
ATOMIC or NOIO allocations, and if the driver is done properly,
it should be able to deal gracefully with failure, typically
for a block driver by triggering a timer to try the request
again later or just fail the request (but that is generally
bad for a block driver).

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/