]> git.hungrycats.org Git - linux/commit
[PATCH] implement __GFP_REPEAT, __GFP_NOFAIL, __GFP_NORETRY
authorAndrew Morton <akpm@digeo.com>
Sun, 20 Apr 2003 07:28:12 +0000 (00:28 -0700)
committerLinus Torvalds <torvalds@home.transmeta.com>
Sun, 20 Apr 2003 07:28:12 +0000 (00:28 -0700)
commit75908778d91e92ca3c9ed587c4550866f4c903fc
tree41ab8b3306f8eb23429dd250ef262ed37dc0634f
parentefbb77b282f9173b4c183aa8ae30772bcb5e580f
[PATCH] implement __GFP_REPEAT, __GFP_NOFAIL, __GFP_NORETRY

This is a cleanup patch.

There are quite a lot of places in the kernel which will infinitely retry a
memory allocation.

Generally, they get it wrong.  Some do yield(), the semantics of which have
changed over time.  Some do schedule(), which can lock up if the caller is
SCHED_FIFO/RR.  Some do schedule_timeout(), etc.

And often it is unnecessary, because the page allocator will do the retry
internally anyway.  But we cannot rely on that - this behaviour may change
(-aa and -rmap kernels do not do this, for instance).

So it is good to formalise and to centralise this operation.  If an
allocation specifies __GFP_REPEAT then the page allocator must infinitely
retry the allocation.

The semantics of __GFP_REPEAT are "try harder".  The allocation _may_ fail
(the 2.4 -aa and -rmap VM's do not retry infinitely by default).

The semantics of __GFP_NOFAIL are "cannot fail".  It is a no-op in this VM,
but needs to be honoured (or fix up the callers) if the VM ischanged to not
retry infinitely by default.

The semantics of __GFP_NOREPEAT are "try once, don't loop".  This isn't used
at present (although perhaps it should be, in swapoff).  It is mainly for
completeness.
include/linux/gfp.h
include/linux/slab.h
mm/page_alloc.c
mm/vmscan.c