On Tue, 2007-06-19 at 16:34 -0700, Christoph Lameter wrote: > On Tue, 19 Jun 2007, Arjan van de Ven wrote: > > > > Otherwise you are locked into the use of GFP_ATOMIC. > > > > all callers pretty much are either in irq context or with spinlocks held. > > Good > > luck..... it's also called primarily from the PCI DMA API which doesn't > > take a > > gfp_t argument in the first place... > > > > so I'm not seeing the point. > > Hmmm... From my superficial look at things it seems that one could avoid > GFP_ATOMIC at times.
by changing ALL drivers. And then you realize the common scenario is that it's taken in irq context ;) > I do not know too much about the driver though but it > seems a bit restrictive to always do GFP_ATOMIC allocs. the only alternative to GFP_ATOMIC is GFP_NOIO which is... barely better. And then add that it can be used only sporadic... feel free to first change all the drivers.. once the callers of these functions have a gfp_t then I'm sure Anil will be happy to take one of those as well ;-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
