Messages in this thread | | | Date | Wed, 24 Jun 2009 13:01:21 -0700 | From | Andrew Morton <> | Subject | Re: upcoming kerneloops.org item: get_page_from_freelist |
| |
On Wed, 24 Jun 2009 12:46:02 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > > On Wed, 24 Jun 2009, Andrew Morton wrote: > > > On Wed, 24 Jun 2009 12:16:20 -0700 (PDT) > > Linus Torvalds <torvalds@linux-foundation.org> wrote: > > > > > Lookie here. This is 2.6.0:mm/page_alloc.c: > > > > > > do_retry = 0; > > > if (!(gfp_mask & __GFP_NORETRY)) { > > > if ((order <= 3) || (gfp_mask & __GFP_REPEAT)) > > > do_retry = 1; > > > if (gfp_mask & __GFP_NOFAIL) > > > do_retry = 1; > > > } > > > if (do_retry) { > > > blk_congestion_wait(WRITE, HZ/50); > > > goto rebalance; > > > } > > > > rebalance: > > if ((p->flags & (PF_MEMALLOC | PF_MEMDIE)) && !in_interrupt()) { > > /* go through the zonelist yet again, ignoring mins */ > > for (i = 0; zones[i] != NULL; i++) { > > struct zone *z = zones[i]; > > > > page = buffered_rmqueue(z, order, cold); > > if (page) > > goto got_pg; > > } > > goto nopage; > > } > > Your point?
That allocation attempts of any order can fail.
> That's the recursive allocation or oom case. Not the normal case at all. > > The _normal_ case is to do the whole "try_to_free_pages()" case and try > and try again. Forever.
If the caller gets oom-killed, the allocation attempt fails. Callers need to handle that.
> IOW, we have traditionally never failed small kernel allocations. It makes > perfect sense that people _depend_ on that. > > Now, we have since relaxed that (a lot). And in answer to that, people > have added more __GFP_NOFAIL flags, I bet. It's all very natural. Claiming > that this is some "new error" and that we should warn about NOFAIL > allocations with big orders is just silly and simply not true. >
There are situations in which the allocation attempt simply will not succeed, so a __GFP_NOFAIL attempt will lock up. Hence callers should stop using __GFP_NOFAIL and should handle the allocation error like 99.9999% of the rest of the kernel does.
The chances of the allocation attempt failing increase with higher-order allocations, hence the combination of __GFP_NOFAIL with order>0 should be avoided more strenuously than __GFP_NOFAIL && order==0.
<Note that the TIF_MEMDIE handling has changed post-2.6.30. I still need to get my head around the end result of what we did there. Did we break the __alloc_pages-fails-if-TFI_MEMDIE logic?>
| |