From: Andrea Arcangeli <andrea@suse.de>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: J Sloan <jjs@toyota.com>, Linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: [lkml]Re: VM problems still in 2.2.18
Date: Fri, 15 Dec 2000 20:09:06 +0100 [thread overview]
Message-ID: <20001215200906.H17781@inspiron.random> (raw)
In-Reply-To: <20001215192207.E17781@inspiron.random> <E146zsJ-0001fT-00@the-village.bc.nu>
In-Reply-To: <E146zsJ-0001fT-00@the-village.bc.nu>; from alan@lxorguk.ukuu.org.uk on Fri, Dec 15, 2000 at 06:46:32PM +0000
On Fri, Dec 15, 2000 at 06:46:32PM +0000, Alan Cox wrote:
> so the actual problem is either - the returning 1 when it is the wrong answer
> - or the failure to block somewhere else (where its safe) based on a kpiod
> maintained semaphore ?
The problem is not to find a safe place where to wait, the problem is to know
"when" we can block. That's the only thing current->fs_locks tells us. Sometime
we simply can't wait because I/O can't start until we return (it would deadlock
regardless we wait on a kpiod semaphore or in down(i_sem) ourselfs).
Once we know "if" we can't wait or not the whole point of kpiod is lost
as kpiod exists only because we didn't know that and so we were not able
to wait.
Now we know when we can block so we can run f_ops->write ourselfs that's also
more efficient in terms of both performance and also memory pressure during
swap of course.
> I assume thats not an issue to reiserfs ?
As said reiserfs AFIK didn't need any change, so only VFS is using
fs_down/fs_up from the point of view of reiserfs.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2000-12-15 19:40 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-12-14 2:36 VM problems still in 2.2.18 Mark Symonds
2000-12-14 9:57 ` Alan Cox
2000-12-14 20:09 ` [lkml]Re: " thunder7
2000-12-14 22:38 ` Alan Cox
2000-12-14 22:39 ` J Sloan
2000-12-14 23:17 ` Alan Cox
2000-12-15 14:29 ` Andrea Arcangeli
2000-12-15 17:57 ` Alan Cox
2000-12-15 18:22 ` Andrea Arcangeli
2000-12-15 18:46 ` Alan Cox
2000-12-15 19:09 ` Andrea Arcangeli [this message]
2000-12-15 19:17 ` Alan Cox
2000-12-16 10:49 ` Chris Mason
2000-12-16 13:39 ` Andrea Arcangeli
2000-12-14 23:12 ` J . A . Magallon
2000-12-18 1:03 ` Mark Symonds
2000-12-15 18:30 ` Mark Symonds
-- strict thread matches above, loose matches on Subject: below --
2000-12-15 13:00 [lkml]Re: " Ed Tomlinson
2000-12-15 17:52 ` Alan Cox
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=20001215200906.H17781@inspiron.random \
--to=andrea@suse.de \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=jjs@toyota.com \
--cc=linux-kernel@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