From: "Stephen C. Tweedie" <sct@redhat.com>
To: Andrea Arcangeli <andrea@suse.de>
Cc: "Stephen C. Tweedie" <sct@redhat.com>,
Rik van Riel <riel@conectiva.com.br>,
Marcelo Tosatti <marcelo@conectiva.com.br>,
Jens Axboe <axboe@suse.de>, Alan Cox <alan@redhat.com>,
Derek Martin <derek@cerberus.ne.mediaone.net>,
Linux Kernel <linux-kernel@vger.rutgers.edu>,
linux-mm@kvack.org
Subject: Re: More 2.2.17pre9 VM issues
Date: Mon, 3 Jul 2000 14:56:42 +0100 [thread overview]
Message-ID: <20000703145642.B3284@redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.21.0007031314190.12740-100000@inspiron.random>; from andrea@suse.de on Mon, Jul 03, 2000 at 01:28:48PM +0200
Hi,
On Mon, Jul 03, 2000 at 01:28:48PM +0200, Andrea Arcangeli wrote:
> Stephen, are we really sure we still need kpiod?i
Yes.
> Isn't GFP_IO meant to be
> clear if anybody is helding any filesystem lock (like superblock lock)?
That has never been a requirement, and I'd think it would be
dangerous to make such a new rule so close to 2.4.
Certainly, in 2.2 we would do all sorts of stuff while holding
filesystem locks (in particular the inode and superblock locks). Any
file write, including mm page writes, would take the inode lock.
Right now, in 2.4, the mm locks less but write(2) still takes the
inode lock. That means that we _must_ be able to allocate with GFP_IO
while holding the inode lock, since (a) write()s go through the page
cache, and (b) touching the user's buffer during the write() can cause
pages to be swapped in, invoking parts of the VM which assume they are
able to use GFP_IO safely.
Sure, you could audit every single path through every filesystem to
make sure that there are no possible deadlocks here, but the whole
point of kpiod is to separate out the pageout from the process doing
the write() in such situations to make deadlock impossible.
Cheers,
Stephen
--
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.eu.org/Linux-MM/
next parent reply other threads:[~2000-07-03 13:56 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20000703111813.D2699@redhat.com>
[not found] ` <Pine.LNX.4.21.0007031314190.12740-100000@inspiron.random>
2000-07-03 13:56 ` Stephen C. Tweedie [this message]
2000-07-03 14:56 ` Andrea Arcangeli
2000-07-03 16:09 ` Stephen C. Tweedie
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=20000703145642.B3284@redhat.com \
--to=sct@redhat.com \
--cc=alan@redhat.com \
--cc=andrea@suse.de \
--cc=axboe@suse.de \
--cc=derek@cerberus.ne.mediaone.net \
--cc=linux-kernel@vger.rutgers.edu \
--cc=linux-mm@kvack.org \
--cc=marcelo@conectiva.com.br \
--cc=riel@conectiva.com.br \
/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