[PATCH] Should GFP_ATOMIC fail when we're below low watermark?

[PATCH] Should GFP_ATOMIC fail when we're below low watermark?

[Nigel Cunningham]

Hi all.

In current git (and for a while now), an attempt to allocate memory with 
GFP_ATOMIC will fail if we're below the low watermark level. The only way to 
access that memory that I can see (not that I've looked that hard) is to have 
PF_MEMALLOC set (ie from kswapd). I'm wondering if this behaviour is correct. 
Shouldn't GFP_ATOMIC allocations ignore watermarks too? How about GFP_KERNEL?

The following patch is a potential fix for GFP_ATOMIC.

Regards,

Nigel

Signed-off-by: Nigel Cunningham <nigel@nigel.suspend2.net>

 page_alloc.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
diff -ruNp 995-gfp-atomic-alloc.patch-old/mm/page_alloc.c 995-gfp-atomic-alloc.patch-new/mm/page_alloc.c
--- 995-gfp-atomic-alloc.patch-old/mm/page_alloc.c	2007-08-20 11:14:34.000000000 +1000
+++ 995-gfp-atomic-alloc.patch-new/mm/page_alloc.c	2007-08-20 11:11:09.000000000 +1000
@@ -1286,8 +1286,8 @@ restart:
 	/* This allocation should allow future memory freeing. */
 
 rebalance:
-	if (((p->flags & PF_MEMALLOC) || unlikely(test_thread_flag(TIF_MEMDIE)))
-			&& !in_interrupt()) {
+	if (((p->flags & PF_MEMALLOC) || unlikely(test_thread_flag(TIF_MEMDIE)) ||
+			(gfp_mask & GFP_ATOMIC)) && !in_interrupt()) {
 		if (!(gfp_mask & __GFP_NOMEMALLOC)) {
 nofail_alloc:
 			/* go through the zonelist yet again, ignoring mins */

-- 
See http://www.tuxonice.net for Howtos, FAQs, mailing
lists, wiki and bugzilla info.

Re: [PATCH] Should GFP_ATOMIC fail when we're below low watermark?

[Peter Zijlstra]

On Mon, 2007-08-20 at 11:38 +1000, Nigel Cunningham wrote:
> Hi all.
> 
> In current git (and for a while now), an attempt to allocate memory with 
> GFP_ATOMIC will fail if we're below the low watermark level. The only way to 
> access that memory that I can see (not that I've looked that hard) is to have 
> PF_MEMALLOC set (ie from kswapd). I'm wondering if this behaviour is correct. 
> Shouldn't GFP_ATOMIC allocations ignore watermarks too? How about GFP_KERNEL?
> 
> The following patch is a potential fix for GFP_ATOMIC.

Sorry, no.

GFP_ATOMIC must fail when below the watermark. GFP_KERNEL has __GFP_WAIT
and hence can sleep and wait for reclaim so that should not be a problem
(usually).

GFP_ATOMIC may not access the reserves because the reserves are needed
to get out of OOM deadlocks within the VM. Consider the fact that
freeing memory needs memory - if there is no memory free, you cannot
free memory and you're pretty much stuck.

Re: [PATCH] Should GFP_ATOMIC fail when we're below low watermark?

[Nigel Cunningham]

Hi.

On Monday 20 August 2007 12:43:50 Peter Zijlstra wrote:
> On Mon, 2007-08-20 at 11:38 +1000, Nigel Cunningham wrote:
> > Hi all.
> > 
> > In current git (and for a while now), an attempt to allocate memory with 
> > GFP_ATOMIC will fail if we're below the low watermark level. The only way 
to 
> > access that memory that I can see (not that I've looked that hard) is to 
have 
> > PF_MEMALLOC set (ie from kswapd). I'm wondering if this behaviour is 
correct. 
> > Shouldn't GFP_ATOMIC allocations ignore watermarks too? How about 
GFP_KERNEL?
> > 
> > The following patch is a potential fix for GFP_ATOMIC.
> 
> Sorry, no.
> 
> GFP_ATOMIC must fail when below the watermark. GFP_KERNEL has __GFP_WAIT
> and hence can sleep and wait for reclaim so that should not be a problem
> (usually).
> 
> GFP_ATOMIC may not access the reserves because the reserves are needed
> to get out of OOM deadlocks within the VM. Consider the fact that
> freeing memory needs memory - if there is no memory free, you cannot
> free memory and you're pretty much stuck.

I guess, then, the question should be whether the watermark values are 
appropriate. Do we need high order allocations watermarked if this is the 
only purpose, particularly considering that whatever memory is allocated for 
this purpose is essentially useless 99.9% of the time?

Regards,

Nigel
-- 
Nigel Cunningham
Christian Reformed Church of Cobden
103 Curdie Street, Cobden 3266, Victoria, Australia
Ph. +61 3 5595 1185 / +61 417 100 574
Communal Worship: 11 am Sunday.

Re: [PATCH] Should GFP_ATOMIC fail when we're below low watermark?

[Peter Zijlstra]

On Mon, 2007-08-20 at 18:38 +1000, Nigel Cunningham wrote:
> Hi.
> 
> On Monday 20 August 2007 12:43:50 Peter Zijlstra wrote:
> > On Mon, 2007-08-20 at 11:38 +1000, Nigel Cunningham wrote:
> > > Hi all.
> > > 
> > > In current git (and for a while now), an attempt to allocate memory with 
> > > GFP_ATOMIC will fail if we're below the low watermark level. The only way 
> to 
> > > access that memory that I can see (not that I've looked that hard) is to 
> have 
> > > PF_MEMALLOC set (ie from kswapd). I'm wondering if this behaviour is 
> correct. 
> > > Shouldn't GFP_ATOMIC allocations ignore watermarks too? How about 
> GFP_KERNEL?
> > > 
> > > The following patch is a potential fix for GFP_ATOMIC.
> > 
> > Sorry, no.
> > 
> > GFP_ATOMIC must fail when below the watermark. GFP_KERNEL has __GFP_WAIT
> > and hence can sleep and wait for reclaim so that should not be a problem
> > (usually).
> > 
> > GFP_ATOMIC may not access the reserves because the reserves are needed
> > to get out of OOM deadlocks within the VM. Consider the fact that
> > freeing memory needs memory - if there is no memory free, you cannot
> > free memory and you're pretty much stuck.
> 
> I guess, then, the question should be whether the watermark values are 
> appropriate. Do we need high order allocations watermarked if this is the 
> only purpose, particularly considering that whatever memory is allocated for 
> this purpose is essentially useless 99.9% of the time?

Could you perhaps explain what you're trying to do? No matter what we
do, GFP_ATOMIC will fail eventually, there is only so much one can do
without blocking.

As for higher order allocations, until we have a full online defrag
solution those too can fail at any moment (even with __GFP_WAIT).

Re: [PATCH] Should GFP_ATOMIC fail when we're below low watermark?

[Nigel Cunningham]

Hi.

On Monday 20 August 2007 18:59:36 Peter Zijlstra wrote:
> On Mon, 2007-08-20 at 18:38 +1000, Nigel Cunningham wrote:
> > Hi.
> > 
> > On Monday 20 August 2007 12:43:50 Peter Zijlstra wrote:
> > > On Mon, 2007-08-20 at 11:38 +1000, Nigel Cunningham wrote:
> > > > Hi all.
> > > > 
> > > > In current git (and for a while now), an attempt to allocate memory 
with 
> > > > GFP_ATOMIC will fail if we're below the low watermark level. The only 
way 
> > to 
> > > > access that memory that I can see (not that I've looked that hard) is 
to 
> > have 
> > > > PF_MEMALLOC set (ie from kswapd). I'm wondering if this behaviour is 
> > correct. 
> > > > Shouldn't GFP_ATOMIC allocations ignore watermarks too? How about 
> > GFP_KERNEL?
> > > > 
> > > > The following patch is a potential fix for GFP_ATOMIC.
> > > 
> > > Sorry, no.
> > > 
> > > GFP_ATOMIC must fail when below the watermark. GFP_KERNEL has __GFP_WAIT
> > > and hence can sleep and wait for reclaim so that should not be a problem
> > > (usually).
> > > 
> > > GFP_ATOMIC may not access the reserves because the reserves are needed
> > > to get out of OOM deadlocks within the VM. Consider the fact that
> > > freeing memory needs memory - if there is no memory free, you cannot
> > > free memory and you're pretty much stuck.
> > 
> > I guess, then, the question should be whether the watermark values are 
> > appropriate. Do we need high order allocations watermarked if this is the 
> > only purpose, particularly considering that whatever memory is allocated 
for 
> > this purpose is essentially useless 99.9% of the time?
> 
> Could you perhaps explain what you're trying to do? No matter what we
> do, GFP_ATOMIC will fail eventually, there is only so much one can do
> without blocking.
> 
> As for higher order allocations, until we have a full online defrag
> solution those too can fail at any moment (even with __GFP_WAIT).

I was just trying to make hibernation more reliable in sitations where there's 
low amounts of memory available. I guess the amount of memory that's reserved 
for this has increased, because some users have been reporting issues that 
hadn't appeared before. No problem. I'll work around it.

Nigel
-- 
See http://www.tuxonice.net for Howtos, FAQs, mailing
lists, wiki and bugzilla info.

Re: [PATCH] Should GFP_ATOMIC fail when we're below low watermark?

[Peter Zijlstra]

On Mon, 2007-08-20 at 20:55 +1000, Nigel Cunningham wrote:
> Hi.
> 
> On Monday 20 August 2007 18:59:36 Peter Zijlstra wrote:
> > On Mon, 2007-08-20 at 18:38 +1000, Nigel Cunningham wrote:
> > > Hi.
> > > 
> > > On Monday 20 August 2007 12:43:50 Peter Zijlstra wrote:
> > > > On Mon, 2007-08-20 at 11:38 +1000, Nigel Cunningham wrote:
> > > > > Hi all.
> > > > > 
> > > > > In current git (and for a while now), an attempt to allocate memory 
> with 
> > > > > GFP_ATOMIC will fail if we're below the low watermark level. The only 
> way 
> > > to 
> > > > > access that memory that I can see (not that I've looked that hard) is 
> to 
> > > have 
> > > > > PF_MEMALLOC set (ie from kswapd). I'm wondering if this behaviour is 
> > > correct. 
> > > > > Shouldn't GFP_ATOMIC allocations ignore watermarks too? How about 
> > > GFP_KERNEL?
> > > > > 
> > > > > The following patch is a potential fix for GFP_ATOMIC.
> > > > 
> > > > Sorry, no.
> > > > 
> > > > GFP_ATOMIC must fail when below the watermark. GFP_KERNEL has __GFP_WAIT
> > > > and hence can sleep and wait for reclaim so that should not be a problem
> > > > (usually).
> > > > 
> > > > GFP_ATOMIC may not access the reserves because the reserves are needed
> > > > to get out of OOM deadlocks within the VM. Consider the fact that
> > > > freeing memory needs memory - if there is no memory free, you cannot
> > > > free memory and you're pretty much stuck.
> > > 
> > > I guess, then, the question should be whether the watermark values are 
> > > appropriate. Do we need high order allocations watermarked if this is the 
> > > only purpose, particularly considering that whatever memory is allocated 
> for 
> > > this purpose is essentially useless 99.9% of the time?
> > 
> > Could you perhaps explain what you're trying to do? No matter what we
> > do, GFP_ATOMIC will fail eventually, there is only so much one can do
> > without blocking.
> > 
> > As for higher order allocations, until we have a full online defrag
> > solution those too can fail at any moment (even with __GFP_WAIT).
> 
> I was just trying to make hibernation more reliable in sitations where there's 
> low amounts of memory available. I guess the amount of memory that's reserved 
> for this has increased, because some users have been reporting issues that 
> hadn't appeared before. No problem. I'll work around it.

I think the last time the default reserves were changed was 2.6.12 or
there about.

Perhaps Mel fiddled with it in .23-rc ?

Re: [PATCH] Should GFP_ATOMIC fail when we're below low watermark?

[Nigel Cunningham]

Hi.

On Monday 20 August 2007 21:06:01 Peter Zijlstra wrote:
> On Mon, 2007-08-20 at 20:55 +1000, Nigel Cunningham wrote:
> > Hi.
> > 
> > On Monday 20 August 2007 18:59:36 Peter Zijlstra wrote:
> > > On Mon, 2007-08-20 at 18:38 +1000, Nigel Cunningham wrote:
> > > > Hi.
> > > > 
> > > > On Monday 20 August 2007 12:43:50 Peter Zijlstra wrote:
> > > > > On Mon, 2007-08-20 at 11:38 +1000, Nigel Cunningham wrote:
> > > > > > Hi all.
> > > > > > 
> > > > > > In current git (and for a while now), an attempt to allocate 
memory 
> > with 
> > > > > > GFP_ATOMIC will fail if we're below the low watermark level. The 
only 
> > way 
> > > > to 
> > > > > > access that memory that I can see (not that I've looked that hard) 
is 
> > to 
> > > > have 
> > > > > > PF_MEMALLOC set (ie from kswapd). I'm wondering if this behaviour 
is 
> > > > correct. 
> > > > > > Shouldn't GFP_ATOMIC allocations ignore watermarks too? How about 
> > > > GFP_KERNEL?
> > > > > > 
> > > > > > The following patch is a potential fix for GFP_ATOMIC.
> > > > > 
> > > > > Sorry, no.
> > > > > 
> > > > > GFP_ATOMIC must fail when below the watermark. GFP_KERNEL has 
__GFP_WAIT
> > > > > and hence can sleep and wait for reclaim so that should not be a 
problem
> > > > > (usually).
> > > > > 
> > > > > GFP_ATOMIC may not access the reserves because the reserves are 
needed
> > > > > to get out of OOM deadlocks within the VM. Consider the fact that
> > > > > freeing memory needs memory - if there is no memory free, you cannot
> > > > > free memory and you're pretty much stuck.
> > > > 
> > > > I guess, then, the question should be whether the watermark values are 
> > > > appropriate. Do we need high order allocations watermarked if this is 
the 
> > > > only purpose, particularly considering that whatever memory is 
allocated 
> > for 
> > > > this purpose is essentially useless 99.9% of the time?
> > > 
> > > Could you perhaps explain what you're trying to do? No matter what we
> > > do, GFP_ATOMIC will fail eventually, there is only so much one can do
> > > without blocking.
> > > 
> > > As for higher order allocations, until we have a full online defrag
> > > solution those too can fail at any moment (even with __GFP_WAIT).
> > 
> > I was just trying to make hibernation more reliable in sitations where 
there's 
> > low amounts of memory available. I guess the amount of memory that's 
reserved 
> > for this has increased, because some users have been reporting issues that 
> > hadn't appeared before. No problem. I'll work around it.
> 
> I think the last time the default reserves were changed was 2.6.12 or
> there about.
> 
> Perhaps Mel fiddled with it in .23-rc ?

Nothing jumps out at me from a quick browse through gitk. I guess I'll just 
shrug my shoulders and get on with life.

Regards,

Nigel
-- 
Nigel Cunningham
Christian Reformed Church of Cobden
103 Curdie Street, Cobden 3266, Victoria, Australia
Ph. +61 3 5595 1185 / +61 417 100 574
Communal Worship: 11 am Sunday.

Re: [PATCH] Should GFP_ATOMIC fail when we're below low watermark?

[Randy Dunlap]

On Mon, 20 Aug 2007 13:06:01 +0200 Peter Zijlstra wrote:

> On Mon, 2007-08-20 at 20:55 +1000, Nigel Cunningham wrote:
> > Hi.
> > 
> > On Monday 20 August 2007 18:59:36 Peter Zijlstra wrote:
> > > On Mon, 2007-08-20 at 18:38 +1000, Nigel Cunningham wrote:
> > > > Hi.
> > > > 
> > > > On Monday 20 August 2007 12:43:50 Peter Zijlstra wrote:
> > > > > On Mon, 2007-08-20 at 11:38 +1000, Nigel Cunningham wrote:
> > > > > > Hi all.
> > > > > > 
> > > > > > In current git (and for a while now), an attempt to allocate memory 
> > with 
> > > > > > GFP_ATOMIC will fail if we're below the low watermark level. The only 
> > way 
> > > > to 
> > > > > > access that memory that I can see (not that I've looked that hard) is 
> > to 
> > > > have 
> > > > > > PF_MEMALLOC set (ie from kswapd). I'm wondering if this behaviour is 
> > > > correct. 
> > > > > > Shouldn't GFP_ATOMIC allocations ignore watermarks too? How about 
> > > > GFP_KERNEL?
> > > > > > 
> > > > > > The following patch is a potential fix for GFP_ATOMIC.
> > > > > 
> > > > > Sorry, no.
> > > > > 
> > > > > GFP_ATOMIC must fail when below the watermark. GFP_KERNEL has __GFP_WAIT
> > > > > and hence can sleep and wait for reclaim so that should not be a problem
> > > > > (usually).
> > > > > 
> > > > > GFP_ATOMIC may not access the reserves because the reserves are needed
> > > > > to get out of OOM deadlocks within the VM. Consider the fact that
> > > > > freeing memory needs memory - if there is no memory free, you cannot
> > > > > free memory and you're pretty much stuck.
> > > > 
> > > > I guess, then, the question should be whether the watermark values are 
> > > > appropriate. Do we need high order allocations watermarked if this is the 
> > > > only purpose, particularly considering that whatever memory is allocated 
> > for 
> > > > this purpose is essentially useless 99.9% of the time?
> > > 
> > > Could you perhaps explain what you're trying to do? No matter what we
> > > do, GFP_ATOMIC will fail eventually, there is only so much one can do
> > > without blocking.
> > > 
> > > As for higher order allocations, until we have a full online defrag
> > > solution those too can fail at any moment (even with __GFP_WAIT).
> > 
> > I was just trying to make hibernation more reliable in sitations where there's 
> > low amounts of memory available. I guess the amount of memory that's reserved 
> > for this has increased, because some users have been reporting issues that 
> > hadn't appeared before. No problem. I'll work around it.
> 
> I think the last time the default reserves were changed was 2.6.12 or
> there about.
> 
> Perhaps Mel fiddled with it in .23-rc ?

Could there be a slab vs. slub difference?

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: [PATCH] Should GFP_ATOMIC fail when we're below low watermark?

[Mel Gorman]

On (20/08/07 13:06), Peter Zijlstra didst pronounce:
> On Mon, 2007-08-20 at 20:55 +1000, Nigel Cunningham wrote:
> > Hi.
> > 
> > On Monday 20 August 2007 18:59:36 Peter Zijlstra wrote:
> > > On Mon, 2007-08-20 at 18:38 +1000, Nigel Cunningham wrote:
> > > > Hi.
> > > > 
> > > > On Monday 20 August 2007 12:43:50 Peter Zijlstra wrote:
> > > > > On Mon, 2007-08-20 at 11:38 +1000, Nigel Cunningham wrote:
> > > > > > Hi all.
> > > > > > 
> > > > > > In current git (and for a while now), an attempt to allocate memory 
> > with 
> > > > > > GFP_ATOMIC will fail if we're below the low watermark level. The only 
> > way 
> > > > to 
> > > > > > access that memory that I can see (not that I've looked that hard) is 
> > to 
> > > > have 
> > > > > > PF_MEMALLOC set (ie from kswapd). I'm wondering if this behaviour is 
> > > > correct. 
> > > > > > Shouldn't GFP_ATOMIC allocations ignore watermarks too? How about 
> > > > GFP_KERNEL?
> > > > > > 
> > > > > > The following patch is a potential fix for GFP_ATOMIC.
> > > > > 
> > > > > Sorry, no.
> > > > > 
> > > > > GFP_ATOMIC must fail when below the watermark. GFP_KERNEL has __GFP_WAIT
> > > > > and hence can sleep and wait for reclaim so that should not be a problem
> > > > > (usually).
> > > > > 
> > > > > GFP_ATOMIC may not access the reserves because the reserves are needed
> > > > > to get out of OOM deadlocks within the VM. Consider the fact that
> > > > > freeing memory needs memory - if there is no memory free, you cannot
> > > > > free memory and you're pretty much stuck.
> > > > 
> > > > I guess, then, the question should be whether the watermark values are 
> > > > appropriate. Do we need high order allocations watermarked if this is the 
> > > > only purpose, particularly considering that whatever memory is allocated 
> > for 
> > > > this purpose is essentially useless 99.9% of the time?
> > > 
> > > Could you perhaps explain what you're trying to do? No matter what we
> > > do, GFP_ATOMIC will fail eventually, there is only so much one can do
> > > without blocking.
> > > 
> > > As for higher order allocations, until we have a full online defrag
> > > solution those too can fail at any moment (even with __GFP_WAIT).
> > 
> > I was just trying to make hibernation more reliable in sitations where there's 
> > low amounts of memory available. I guess the amount of memory that's reserved 
> > for this has increased, because some users have been reporting issues that 
> > hadn't appeared before. No problem. I'll work around it.
> 
> I think the last time the default reserves were changed was 2.6.12 or
> there about.
> 
> Perhaps Mel fiddled with it in .23-rc ?
> 

I haven't changed how this works as such. When ZONE_MOVABLE is
configured, then the reserves will be higher than normal because of how
sysctl_lowmem_reserve_ratio[] works. But in the normal cases like we're
dealing with here, the ratios remain unchanged.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

Re: [PATCH] Should GFP_ATOMIC fail when we're below low watermark?

[Rafael J. Wysocki]

On Monday, 20 August 2007 12:55, Nigel Cunningham wrote:
> Hi.
> 
> On Monday 20 August 2007 18:59:36 Peter Zijlstra wrote:
> > On Mon, 2007-08-20 at 18:38 +1000, Nigel Cunningham wrote:
> > > Hi.
> > > 
> > > On Monday 20 August 2007 12:43:50 Peter Zijlstra wrote:
> > > > On Mon, 2007-08-20 at 11:38 +1000, Nigel Cunningham wrote:
> > > > > Hi all.
> > > > > 
> > > > > In current git (and for a while now), an attempt to allocate memory 
> with 
> > > > > GFP_ATOMIC will fail if we're below the low watermark level. The only 
> way 
> > > to 
> > > > > access that memory that I can see (not that I've looked that hard) is 
> to 
> > > have 
> > > > > PF_MEMALLOC set (ie from kswapd). I'm wondering if this behaviour is 
> > > correct. 
> > > > > Shouldn't GFP_ATOMIC allocations ignore watermarks too? How about 
> > > GFP_KERNEL?
> > > > > 
> > > > > The following patch is a potential fix for GFP_ATOMIC.
> > > > 
> > > > Sorry, no.
> > > > 
> > > > GFP_ATOMIC must fail when below the watermark. GFP_KERNEL has __GFP_WAIT
> > > > and hence can sleep and wait for reclaim so that should not be a problem
> > > > (usually).
> > > > 
> > > > GFP_ATOMIC may not access the reserves because the reserves are needed
> > > > to get out of OOM deadlocks within the VM. Consider the fact that
> > > > freeing memory needs memory - if there is no memory free, you cannot
> > > > free memory and you're pretty much stuck.
> > > 
> > > I guess, then, the question should be whether the watermark values are 
> > > appropriate. Do we need high order allocations watermarked if this is the 
> > > only purpose, particularly considering that whatever memory is allocated 
> for 
> > > this purpose is essentially useless 99.9% of the time?
> > 
> > Could you perhaps explain what you're trying to do? No matter what we
> > do, GFP_ATOMIC will fail eventually, there is only so much one can do
> > without blocking.
> > 
> > As for higher order allocations, until we have a full online defrag
> > solution those too can fail at any moment (even with __GFP_WAIT).
> 
> I was just trying to make hibernation more reliable in sitations where there's 
> low amounts of memory available. I guess the amount of memory that's reserved 
> for this has increased, because some users have been reporting issues that 
> hadn't appeared before. No problem. I'll work around it.

Can you please point me to these reports, BTW?

Greetings,
Rafael

Re: [PATCH] Should GFP_ATOMIC fail when we're below low watermark?

[Mel Gorman]

On (20/08/07 20:55), Nigel Cunningham didst pronounce:
> Hi.
> 
> On Monday 20 August 2007 18:59:36 Peter Zijlstra wrote:
> > On Mon, 2007-08-20 at 18:38 +1000, Nigel Cunningham wrote:
> > > Hi.
> > > 
> > > On Monday 20 August 2007 12:43:50 Peter Zijlstra wrote:
> > > > On Mon, 2007-08-20 at 11:38 +1000, Nigel Cunningham wrote:
> > > > > Hi all.
> > > > > 
> > > > > In current git (and for a while now), an attempt to allocate memory 
> with 
> > > > > GFP_ATOMIC will fail if we're below the low watermark level. The only 
> way 
> > > to 
> > > > > access that memory that I can see (not that I've looked that hard) is 
> to 
> > > have 
> > > > > PF_MEMALLOC set (ie from kswapd). I'm wondering if this behaviour is 
> > > correct. 
> > > > > Shouldn't GFP_ATOMIC allocations ignore watermarks too? How about 
> > > GFP_KERNEL?
> > > > > 
> > > > > The following patch is a potential fix for GFP_ATOMIC.
> > > > 
> > > > Sorry, no.
> > > > 
> > > > GFP_ATOMIC must fail when below the watermark. GFP_KERNEL has __GFP_WAIT
> > > > and hence can sleep and wait for reclaim so that should not be a problem
> > > > (usually).
> > > > 
> > > > GFP_ATOMIC may not access the reserves because the reserves are needed
> > > > to get out of OOM deadlocks within the VM. Consider the fact that
> > > > freeing memory needs memory - if there is no memory free, you cannot
> > > > free memory and you're pretty much stuck.
> > > 
> > > I guess, then, the question should be whether the watermark values are 
> > > appropriate. Do we need high order allocations watermarked if this is the 
> > > only purpose, particularly considering that whatever memory is allocated 
> for 
> > > this purpose is essentially useless 99.9% of the time?
> > 
> > Could you perhaps explain what you're trying to do? No matter what we
> > do, GFP_ATOMIC will fail eventually, there is only so much one can do
> > without blocking.
> > 
> > As for higher order allocations, until we have a full online defrag
> > solution those too can fail at any moment (even with __GFP_WAIT).
> 
> I was just trying to make hibernation more reliable in sitations where there's 
> low amounts of memory available. I guess the amount of memory that's reserved 
> for this has increased, because some users have been reporting issues that 
> hadn't appeared before. No problem. I'll work around it.

Where are these reports? I'm not familiar with how hibernation works but
why does it need a large number of GFP_ATOMIC allocations?

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab