[1/13] add __GFP_NOKILL

[1/13] add __GFP_NOKILL

[William Lee Irwin III]

__GFP_NOKILL has the semantics that OOM killing should never result
from the given allocation. Instead, the allocation should be failed,
as it's not indicative of the system being truly out of memory, only
that the given call cannot be serviced.

The series of patches using this flag to prevent spurious OOM killing
were all done in response to specific OOM's observed during testing.


diff -urN linux-2.5.33/include/linux/gfp.h linux-2.5.33-mm5/include/linux/gfp.h
--- linux-2.5.33/include/linux/gfp.h	2002-08-31 15:04:53.000000000 -0700
+++ linux-2.5.33-mm5/include/linux/gfp.h	2002-09-08 19:52:51.000000000 -0700
@@ -17,6 +17,7 @@
 #define __GFP_IO	0x40	/* Can start low memory physical IO? */
 #define __GFP_HIGHIO	0x80	/* Can start high mem physical IO? */
 #define __GFP_FS	0x100	/* Can call down to low-level FS? */
+#define __GFP_NOKILL	0x200	/* Should not OOM kill */
 
 #define GFP_NOHIGHIO	(             __GFP_WAIT | __GFP_IO)
 #define GFP_NOIO	(             __GFP_WAIT)
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: [1/13] add __GFP_NOKILL

[William Lee Irwin III]

On Wed, Sep 25, 2002 at 10:42:20PM -0700, William Lee Irwin III wrote:
> --- linux-2.5.33/include/linux/gfp.h	2002-08-31 15:04:53.000000000 -0700
> +++ linux-2.5.33-mm5/include/linux/gfp.h	2002-09-08 19:52:51.000000000 -0700

Despite these lines saying 2.5.33, these are all rediffs of the 2.5.33-mm5
patches against 2.5.38-mm2.


Cheers,
Bill
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: [1/13] add __GFP_NOKILL

[Andrew Morton]

Andrea just disabled out_of_memory().

We need to find out why these oom-killings are happening
in the first place.  They probably all have a common cause.

Please arrange to dump the state of all zones and page_states[]
when it happens.

Adding:

static struct page_state wli_state;

get_page_state(struct page_state *ps)
{
	...
	*wli = *ps;
	return;
}

in page_alloc.c makes the latter easier.

As we discussed, be suspicious of your fallback lists.  Otherwise
it _might_ be the zone-unaware throttling.  I want to know, please,
before I go and add lots of sleep/wakeup gunk to try_to_free_pages()
and end_page_writeback().

Critical question: how much dirty memory is in the normal
zone?  To determine this, look at the last three functions
in mm/page_writeback.c.  Make them do

	atomic_inc/dec(&page_zone(page)->nr-dirty);

thanks.

Also it is important to know the size of the active/inactive
lists in those zones.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/