Re: __GFP flags and kmalloc failures

[Marcelo Tosatti]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/