![]() | ||||||||||
Messages in this thread |
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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | |||||||||
| Last update: 2008-03-24 18:51 [W:0.273 / U:0.100 seconds] ©2003-2008 Jasper Spaans | ||||||||||