From: Ingo Molnar <mingo@elte.hu>
To: Nathan Scott <nathans@sgi.com>
Cc: Christoph Hellwig <hch@infradead.org>,
Steven Whitehouse <swhiteho@redhat.com>,
Linus Torvalds <torvalds@osdl.org>,
David Teigland <teigland@redhat.com>,
Patrick Caulfield <pcaulfie@redhat.com>,
Kevin Anderson <kanderso@redhat.com>,
Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org
Subject: Re: GFS2 and DLM
Date: Tue, 27 Jun 2006 10:51:24 +0200 [thread overview]
Message-ID: <20060627085124.GA1487@elte.hu> (raw)
In-Reply-To: <20060627184237.A1295371@wobbly.melbourne.sgi.com>
* Nathan Scott <nathans@sgi.com> wrote:
> > and since XFS makes use of KM_SLEEP in 130+ callsites, that means it
> > is in essence using GFP_NOFAIL massively!
>
> Their locations have been carefully audited and understood. The
> original issue here was IRIX being able to do a very good of
> preventing kernel memory allocation failures, which I suspect caused
> the original XFS guys to be fairly relaxed in their handling of memory
> allocation failures. Its caused us no end of pain with the Linux port,
> I assure you.
i know it's a hard problem, and i'm not suggesting at all that this is
easy to fix. Nevertheless there are 130 allocation callsites in XFS that
do implicit GFS_NOFAIL in essence, and 7 callsites in GFS2 that mention
__GFS_NOFAIL explicitly. Ext3 does __GFP_NOFAIL in its journalling code
too. Reiser too.
Ingo
next prev parent reply other threads:[~2006-06-27 8:56 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-20 12:17 GFS2 and DLM Steven Whitehouse
2006-06-20 12:32 ` Nick Piggin
2006-06-20 12:47 ` Steven Whitehouse
2006-06-20 14:04 ` Nick Piggin
2006-06-20 15:40 ` Steven Whitehouse
2006-06-20 19:55 ` Andrew Morton
2006-06-21 11:20 ` Steven Whitehouse
2006-06-23 14:45 ` Christoph Hellwig
2006-06-26 21:03 ` Ingo Molnar
2006-06-27 7:52 ` Christoph Hellwig
2006-06-20 12:33 ` Christoph Hellwig
2006-06-20 12:55 ` Steven Whitehouse
2006-06-20 15:55 ` Ingo Molnar
2006-06-23 14:49 ` Christoph Hellwig
2006-06-23 20:46 ` Andrew Morton
2006-06-26 20:03 ` Ingo Molnar
2006-06-26 20:12 ` Arjan van de Ven
2006-06-27 7:08 ` Ingo Molnar
2006-06-27 6:33 ` Ingo Molnar
2006-06-27 6:43 ` Arjan van de Ven
2006-06-27 7:07 ` Ingo Molnar
2006-06-27 7:06 ` Andrew Morton
2006-06-27 8:35 ` Ingo Molnar
2006-06-27 8:50 ` Andrew Morton
2006-06-27 9:04 ` Ingo Molnar
2006-06-27 9:23 ` Andrew Morton
2006-07-03 13:40 ` Steven Whitehouse
2006-06-27 8:16 ` Nathan Scott
2006-06-27 8:22 ` Ingo Molnar
2006-06-27 8:41 ` Pekka Enberg
2006-06-27 10:33 ` Ingo Molnar
2006-06-27 8:42 ` Nathan Scott
2006-06-27 8:51 ` Ingo Molnar [this message]
2006-06-23 14:54 ` Christoph Hellwig
2006-06-23 15:54 ` Steven Whitehouse
2006-06-23 15:54 ` Christoph Hellwig
2006-06-23 16:09 ` Steven Whitehouse
2006-06-23 14:55 ` Christoph Hellwig
2006-06-23 14:57 ` Christoph Hellwig
2006-06-23 15:26 ` Steven Whitehouse
2006-06-23 15:00 ` Christoph Hellwig
2006-06-23 16:29 ` Steven Whitehouse
2006-06-23 16:48 ` Christoph Hellwig
2006-06-26 20:58 ` Ingo Molnar
2006-06-27 7:50 ` Christoph Hellwig
2006-06-27 8:31 ` Ingo Molnar
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=20060627085124.GA1487@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@osdl.org \
--cc=hch@infradead.org \
--cc=kanderso@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nathans@sgi.com \
--cc=pcaulfie@redhat.com \
--cc=swhiteho@redhat.com \
--cc=teigland@redhat.com \
--cc=torvalds@osdl.org \
/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.