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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux