All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Nick Piggin <npiggin@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, davem@davemloft.net,
	Trond Myklebust <trond.myklebust@fys.uio.no>
Subject: Re: [patch] nfs: use GFP_NOFS preloads for radix-tree insertion
Date: Wed, 14 Nov 2007 10:06:27 +0100	[thread overview]
Message-ID: <1195031187.6924.1.camel@twins> (raw)
In-Reply-To: <20071114042011.GE557@wotan.suse.de>

On Wed, 2007-11-14 at 05:20 +0100, Nick Piggin wrote:
> On Tue, Nov 13, 2007 at 11:55:45AM +0100, Peter Zijlstra wrote:
> > 
> > On Thu, 2007-11-08 at 07:56 +0100, Nick Piggin wrote:
> > > Here is the NFS version. I guess Trond should ack it before you pick it
> > > up.
> > > 
> > > --
> > > 
> > > NFS should use GFP_NOFS mode radix tree preloads rather than GFP_ATOMIC
> > > allocations at radix-tree insertion-time. This is important to reduce the
> > > atomic memory requirement.
> > 
> > In another mail you said:
> > 
> > > Anyway we can also simplify the code because the insertion can't fail with a
> > > preload.
> > 
> > Can we please avoid adding strict dependencies on that as the preload
> > API is unsupportable in -rt.
> 
> You can surely support it. You just have to do per-thread preloads if you
> want preemption left on.

Well, true, but that would mean adding stuff to task_struct, not the end
of the world I guess.

But as it is leaving the error handling on each individual
radix_tree_insert() allows us to just use GFP_KERNEL for everything.

The other, nicer option, is to do preload on the radix_tree_context
object instead.


--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2007-11-14  9:06 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-08  0:43 [patch] radix-tree: avoid atomic allocations for preloaded insertions Nick Piggin
2007-11-08  1:09 ` Andrew Morton
2007-11-08  1:34   ` David Miller, Andrew Morton
2007-11-08  1:41     ` Andrew Morton
2007-11-08  1:45       ` David Miller, Andrew Morton
2007-11-08  1:37   ` Nick Piggin
2007-11-08  3:02     ` Andrew Morton
2007-11-08  3:16       ` Nick Piggin
2007-11-08  4:12         ` Andrew Morton
2007-11-08  4:54           ` Nick Piggin
2007-11-08  5:02             ` Andrew Morton
2007-11-08  5:44               ` Nick Piggin
2007-11-08  6:02                 ` Andrew Morton
2007-11-08  6:54                   ` Nick Piggin
2007-11-08  6:56                   ` [patch] nfs: use GFP_NOFS preloads for radix-tree insertion Nick Piggin
2007-11-13 10:55                     ` Peter Zijlstra
2007-11-14  4:20                       ` Nick Piggin
2007-11-14  9:06                         ` Peter Zijlstra [this message]
2007-11-14 15:39                           ` Nick Piggin
2007-11-08 11:57           ` [patch] radix-tree: avoid atomic allocations for preloaded insertions Peter Zijlstra
2007-11-08 20:37             ` Nick Piggin
2007-11-08 20:47               ` Peter Zijlstra

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=1195031187.6924.1.camel@twins \
    --to=peterz@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=linux-mm@kvack.org \
    --cc=npiggin@suse.de \
    --cc=trond.myklebust@fys.uio.no \
    /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.