On Mon, 24 Mar 2008 09:53:16 -0500 Timur Tabi <[EMAIL PROTECTED]> 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. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
