All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans Reiser <reiser@namesys.com>
To: Andrew Morton <akpm@osdl.org>
Cc: Pekka J Enberg <penberg@cs.Helsinki.FI>,
	linux-kernel@vger.kernel.org, reiserfs-dev@namesys.com
Subject: Re: [PATCH] reiserfs: use __GFP_NOFAIL instead of yield and retry loop for allocation
Date: Fri, 13 Jan 2006 13:44:11 -0800	[thread overview]
Message-ID: <43C81F2B.3020802@namesys.com> (raw)
In-Reply-To: <20060112235548.0e1e4343.akpm@osdl.org>

Do you guys think you could write some nice long comments on these flags
regarding what they mean and the policies for using them?

I gotta tell you, lots of people end up just guessing as best as they can.

Hans

Andrew Morton wrote:

>Pekka J Enberg <penberg@cs.Helsinki.FI> wrote:
>  
>
>>Hi,
>>
>>Pekka J Enberg <penberg@cs.Helsinki.FI> wrote:
>>    
>>
>>>> -      retry:
>>>> -	jl = kzalloc(sizeof(struct reiserfs_journal_list), GFP_NOFS);
>>>> -	if (!jl) {
>>>> -		yield();
>>>> -		goto retry;
>>>> -	}
>>>> +	jl = kzalloc(sizeof(struct reiserfs_journal_list),
>>>> +		     GFP_NOFS | __GFP_NOFAIL);
>>>>        
>>>>
>>On Thu, 12 Jan 2006, Andrew Morton wrote:
>>    
>>
>>>yup, that's what __GFP_NOFAIL is for: to consolidate and identify all those
>>>places which want to lock up when we're short of memory...  They all need
>>>fixing, really.
>>>      
>>>
>>Out of curiosity, are there any potential problems with combining GFP_NOFS 
>>and __GFP_NOFAIL? Can we really guarantee to give out memory if we're not 
>>allowed to page out?
>>
>>    
>>
>
>GFP_NOFS increases the risk (relative to GFP_KERNEL) because page reclaim
>can do less things than GFP_KERNEL to free memory.
>
>GFP_NOFS allocations can still perform swapspace writes, however.  GFP_NOIO
>cannot even do that.
>
>
>  
>


      reply	other threads:[~2006-01-13 21:44 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-13  7:33 [PATCH] reiserfs: use __GFP_NOFAIL instead of yield and retry loop for allocation Pekka J Enberg
2006-01-13  7:42 ` Andrew Morton
2006-01-13  7:46   ` Pekka J Enberg
2006-01-13  7:55     ` Andrew Morton
2006-01-13 21:44       ` Hans Reiser [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=43C81F2B.3020802@namesys.com \
    --to=reiser@namesys.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=penberg@cs.Helsinki.FI \
    --cc=reiserfs-dev@namesys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.