GFP_ATOMIC versus GFP_NOWAIT

GFP_ATOMIC versus GFP_NOWAIT

[Dan Williams]

Looking through the tree it seems that almost all drivers that need to
allocate memory in atomic contexts use GFP_ATOMIC.  I have been asking
dmaengine device driver authors to switch their atomic allocations to
GFP_NOWAIT.  The rationale being that in most cases a dma device is
either offloading an operation that will automatically fallback to
software when the descriptor allocation fails, or we can simply poll
and wait for the dma device to release some in use descriptors.  So it
does not make sense to grab from the emergency pools when the result
of an allocation failure is some additional cpu overhead.  Am I
correct in my nagging, and should this idea be spread outside of
drivers/dma/ to cut down on GFP_ATOMIC usage, or is this not a big
issue?

Thanks,
Dan

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: GFP_ATOMIC versus GFP_NOWAIT

[Andi Kleen]

Dan Williams <dan.j.williams@intel.com> writes:

> Looking through the tree it seems that almost all drivers that need to
> allocate memory in atomic contexts use GFP_ATOMIC.  I have been asking
> dmaengine device driver authors to switch their atomic allocations to
> GFP_NOWAIT.  The rationale being that in most cases a dma device is
> either offloading an operation that will automatically fallback to
> software when the descriptor allocation fails, or we can simply poll
> and wait for the dma device to release some in use descriptors.  So it
> does not make sense to grab from the emergency pools when the result
> of an allocation failure is some additional cpu overhead.  Am I
> correct in my nagging, and should this idea be spread outside of
> drivers/dma/ to cut down on GFP_ATOMIC usage, or is this not a big
> issue?

It's probably hard to find a good global priority order between
the various allocators, depending on how much the fallback costs. 
But in principle it sounds like a good idea.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>