Re: [PATCH 1/2 v2] Driver for Freescale 8610 and 5121 DIU

[Andrew Morton <akpm@linux-foundation.org>]

On Mon, 24 Mar 2008 09:53:16 -0500
Timur Tabi <timur@freescale.com> wrote:

> Andrew Morton wrote:
> 
> >>> GFP_DMA implies GFP_ATOMIC, but it's appropriate for documentation purposes.
> >> So does that mean that "GFP_DMA | GFP_KERNEL" is always wrong?
> > 
> > No, that's OK too.  It's just that GFP_DMA|GFP_ATOMIC is a bit redundant
> > and misleading.  GFP_DMA is already atomic; the only effect of adding
> > GFP_ATOMIC to GFP_DMA is to add __GFP_HIGH.
> > 
> > Don't wory about it ;)
> 
> Well, maybe we don't want GFP_ATOMIC then, because I don't think we want
> __GFP_HIGH.  Looking at the code, it appears the __GFP_HIGH has nothing to do
> with HIGHMEM (which on PowerPC is the not 1-to-1 mapping memory from 0xF000000
> to 0xFFFFFFFF).  Further examination of the cools shows the __GFP_HIGH says to
> try access the "emergency pool", and I see this code snippet:
> 
> 	if (alloc_flags & ALLOC_HIGH)
> 		min -= min / 2;
> 
> I guess this means that we reduce the amount of memory that can be available in
> order for the allocate to succeed.
> 
> Considering that the amount of memory that we allocate is in the order of
> megabytes, and it really isn't that important, I would think that we don't want
> to touch the emergency pool.  Does that sound right?

yup.  The absence of __GFP_WAIT already causes the page allocator to try a
bit harder.  Adding __GFP_HIGH would make it try harder still.

You do need to be sure that the driver will robustly and correctly recover
from an allocation failure here.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/