From: Trond Myklebust <Trond.Myklebust@netapp.com>
To: Chris Mason <chris.mason@oracle.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linux-nfs@vger.kernel.org
Subject: Re: [PATCH] VM: kswapd should not do blocking memory allocations
Date: Wed, 18 Aug 2010 16:10:10 -0400 [thread overview]
Message-ID: <1282162210.8540.100.camel@heimdal.trondhjem.org> (raw)
In-Reply-To: <20100818193440.GZ5854@think>
On Wed, 2010-08-18 at 15:34 -0400, Chris Mason wrote:
> On Wed, Aug 18, 2010 at 03:04:01PM -0400, Trond Myklebust wrote:
> > From: Trond Myklebust <Trond.Myklebust@netapp.com>
> >
> > Allowing kswapd to do GFP_KERNEL memory allocations (or any blocking memory
> > allocations) is wrong and can cause deadlocks in try_to_release_page(), as
> > the filesystem believes it is safe to allocate new memory and block,
> > whereas kswapd is there specifically to clear a low-memory situation...
> >
> > Set the gfp_mask to GFP_IOFS instead.
>
> I always thought releasepage was supposed to do almost zero work. It
> could release an instantly freeable page but it wasn't supposed to dive
> in and solve world hunger or anything.
>
> I thought the VM would be using writepage for that.
writepage isn't sufficient for the NFS case: the page may be in the
'clean but unstable' state, in which case the NFS client needs to send a
COMMIT rpc call before the page can finally be released.
That is why we need the gfp_flag to tell us when it is safe to do this,
and when it is not.
The main case where it is safe and necessary for try_to_release_page()
to initiate a COMMIT call is in the invalidate_inode_pages2(). We might
want to do it in the kswapd case too, but in that case, we definitely
should tell the filesystem that it is unsafe to block.
Trond
next prev parent reply other threads:[~2010-08-18 20:10 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-18 19:04 [PATCH] VM: kswapd should not do blocking memory allocations Trond Myklebust
[not found] ` <AANLkTi=WkoxjwZbt6Vd0VhbuA7_k2WM-NUXZnrmzOOPy@mail.gmail.com>
2010-08-18 19:31 ` Trond Myklebust
2010-08-20 5:45 ` Wu Fengguang
2010-08-20 12:17 ` Trond Myklebust
2010-08-18 19:34 ` Chris Mason
2010-08-18 20:10 ` Trond Myklebust [this message]
2010-08-20 5:40 ` Wu Fengguang
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=1282162210.8540.100.camel@heimdal.trondhjem.org \
--to=trond.myklebust@netapp.com \
--cc=chris.mason@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nfs@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).