Messages in this thread | | | Date | Mon, 24 Mar 2008 11:47:40 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH 1/2 v2] Driver for Freescale 8610 and 5121 DIU |
| |
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.
| |