Messages in this thread | | | Date | Tue, 2 Nov 2004 13:55:46 -0200 | From | Marcelo Tosatti <> | Subject | Re: __GFP flags and kmalloc failures |
| |
On Tue, Nov 02, 2004 at 07:31:39PM +0100, Pierre Ossman wrote: > Marcelo Tosatti wrote: > > >On Tue, Nov 02, 2004 at 07:01:55PM +0100, Pierre Ossman wrote: > > > > > >>Is there any other way of increasing the chances of actually getting the > >>pages I need? Since it is DMA it needs to be one big block. > >> > >> > > > >__GFP_NOFAIL, from gfp.h: > > > >* Action modifiers - doesn't change the zoning > >* > >* __GFP_REPEAT: Try hard to allocate the memory, but the allocation attempt > >* _might_ fail. This depends upon the particular VM implementation. > >* > >* __GFP_NOFAIL: The VM implementation _must_ retry infinitely: the caller > >* cannot handle allocation failures. > >* > >* __GFP_NORETRY: The VM implementation must not retry indefinitely. > >*/ > > > > > > > Yes, I've browsed through these. __GFP_NOFAIL seems like it can hang for > a very long time (I don't know if there is an upper bound on how long it > will have to wait for a free page). __GFP_REPEAT seems to work good > enough in this case. > My question was meant to be more along the lines of "Is there anything I > can do without resorting to unstable/interal API:s?".
Not really.
They are not that unstable, I shouldnt mean that.
These defines are not as stable as system calls - VM internals might change in v2.7 and the flags also - but for v2.6 they are very likely to remain untouched.
Its just like any driver API in Linux - they change.
Just keep an eye. - 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/
| |