From: Jan Hudec <bulb@ucw.cz>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: hbryan@us.ibm.com, akpm@osdl.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, pavel@ucw.cz, torvalds@osdl.org
Subject: Re: [PATCH] [Request for inclusion] Filesystem in Userspace
Date: Thu, 18 Nov 2004 23:00:02 +0100 [thread overview]
Message-ID: <20041118220002.GI2870@vagabond> (raw)
In-Reply-To: <E1CUsJX-0004Q6-00@dorka.pomaz.szeredi.hu>
[-- Attachment #1: Type: text/plain, Size: 1845 bytes --]
On Thu, Nov 18, 2004 at 20:51:31 +0100, Miklos Szeredi wrote:
> > The "allocation" is a fetch or store instruction by the FUSE process,
> > which generates a page fault. To satisfy that, the kernel has to allocate
> > some real memory. A fetch or store instruction doesn't fail when there's
> > no real memory available. It just waits for the kernel to make some
> > available. The kernel does that by picking some less deserving page and
> > evicting it. That eviction may require a pageout. If the guy who's doing
> > the fetch or store is the guy who's supposed to do that pageout, you have
> > a deadlock.
>
> OK. I still maintaintain, that this is an impossible situation, but
> maybe I'm wrong.
No. It is a hard-to-see, but real situation.
> > Furthermore, it's not right for the write() to fail or for any process to
> > be killed by the OOM Killer. The system has the resources to complete the
> > job. It just hasn't scheduled them correctly and thus backed itself into
> > a corner.
>
> Yes, but a kernel based filesystem would be in the same situation.
> It's not a problem unique to userspace filesystems. And I think the
> kernel is careful enough not to get into the corner. So there's no
> problem.
The kernel may also have that problem and solves it the
not-exactly-right way -- by unleashing the OOM killer. But FUSE won't
unleash the OOM killer -- it will deadlock the swapper, because the
swapper waits for the fuse process and the fuse process won't run until
the swapper cleans some pages. Because the swapper does not know, that
trying to writeout pages is futile since this request is from writeout
path. It does know in the in-kernel case.
-------------------------------------------------------------------------------
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
prev parent reply other threads:[~2004-11-18 22:00 UTC|newest]
Thread overview: 119+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-15 21:15 [PATCH] [Request for inclusion] Filesystem in Userspace Miklos Szeredi
2004-11-15 21:43 ` Greg KH
2004-11-15 22:35 ` Linus Torvalds
2004-11-16 9:08 ` Miklos Szeredi
2004-11-16 9:18 ` Arjan van de Ven
2004-11-16 9:40 ` Miklos Szeredi
2004-11-16 9:46 ` Arjan van de Ven
2004-11-16 9:52 ` Miklos Szeredi
2004-11-16 10:17 ` David Woodhouse
2004-11-16 10:25 ` Miklos Szeredi
2004-11-16 10:13 ` Pekka Enberg
2004-11-16 10:20 ` Miklos Szeredi
2004-11-16 10:35 ` Pekka Enberg
2004-11-16 10:42 ` Miklos Szeredi
2004-11-16 12:19 ` Pekka Enberg
2004-11-16 11:02 ` Jan Kratochvil
2004-11-16 14:01 ` Miklos Szeredi
2004-11-16 16:33 ` Greg KH
2004-11-16 16:45 ` Miklos Szeredi
2004-11-16 17:03 ` Greg KH
2004-11-16 17:50 ` Miklos Szeredi
2004-11-16 17:58 ` Greg KH
2004-11-16 19:09 ` Miklos Szeredi
2004-11-16 19:16 ` Greg KH
2004-11-16 19:30 ` Miklos Szeredi
2004-11-16 19:38 ` Greg KH
2004-11-16 19:24 ` Jan Engelhardt
2004-11-16 19:32 ` Miklos Szeredi
2004-11-16 19:42 ` Anton Altaparmakov
2004-11-16 19:48 ` Jan Engelhardt
2004-11-16 20:12 ` Miklos Szeredi
2004-11-17 15:42 ` Miklos Szeredi
2004-11-17 16:57 ` Nikita Danilov
2004-11-17 17:10 ` Jan Engelhardt
2004-11-17 17:33 ` Nikita Danilov
2004-11-17 17:38 ` Jan Engelhardt
2004-11-17 17:58 ` Nikita Danilov
2004-11-17 18:09 ` Jan Engelhardt
2004-11-17 19:58 ` Mike Waychison
2004-11-17 18:53 ` [PATCH] " Al Viro
2004-11-17 17:56 ` Miklos Szeredi
2004-11-17 18:11 ` Greg KH
2004-11-17 18:17 ` Miklos Szeredi
2004-11-17 18:20 ` Nikita Danilov
2004-11-17 17:52 ` Greg KH
2004-11-17 15:36 ` Alan Cox
2004-11-17 21:37 ` Bryan Henderson
2004-11-17 19:00 ` Pavel Machek
2004-11-17 19:45 ` Miklos Szeredi
2004-11-17 20:44 ` Pavel Machek
2004-11-18 8:17 ` Miklos Szeredi
2004-11-18 14:46 ` Pavel Machek
2004-11-21 7:42 ` Miklos Szeredi
2004-11-21 7:50 ` Miklos Szeredi
2004-11-21 9:50 ` Jan Hudec
2004-11-21 10:31 ` Miklos Szeredi
2004-11-21 10:39 ` Jan Hudec
2004-11-21 11:29 ` Miklos Szeredi
2004-11-21 11:53 ` Anton Altaparmakov
2004-11-21 12:01 ` Miklos Szeredi
2004-11-21 18:13 ` Pavel Machek
2004-11-22 16:12 ` Miklos Szeredi
2004-11-18 17:00 ` Bryan Henderson
2004-11-18 17:14 ` Miklos Szeredi
2004-11-18 18:49 ` Bryan Henderson
2004-11-18 19:12 ` Miklos Szeredi
2004-11-19 7:01 ` Jan Engelhardt
2004-11-20 12:00 ` Jan Hudec
2004-11-18 17:12 ` Bryan Henderson
2004-11-18 17:28 ` Miklos Szeredi
2004-11-18 18:01 ` Linus Torvalds
2004-11-18 17:29 ` Alan Cox
2004-11-18 18:55 ` Linus Torvalds
2004-11-18 19:28 ` Miklos Szeredi
2004-11-19 9:46 ` Pavel Machek
2004-11-18 20:57 ` Andrew Morton
2004-11-24 6:20 ` Daniel Phillips
2004-11-24 12:15 ` Avi Kivity
2004-11-24 13:05 ` Miklos Szeredi
[not found] ` <200411242001.59504.oliver@neukum.org>
2004-11-24 19:20 ` Miklos Szeredi
2004-11-25 6:26 ` Jan Hudec
2004-11-25 7:29 ` Miklos Szeredi
2004-11-25 7:47 ` Jan Hudec
2004-11-25 9:15 ` Miklos Szeredi
2004-11-25 9:54 ` Pavel Machek
2004-11-30 18:44 ` Avi Kivity
2004-11-30 19:16 ` Miklos Szeredi
2004-11-30 19:55 ` Avi Kivity
2004-11-30 21:13 ` Miklos Szeredi
2004-11-30 21:37 ` Avi Kivity
2004-11-30 21:58 ` Miklos Szeredi
2004-11-30 22:57 ` Avi Kivity
2004-11-30 23:19 ` Miklos Szeredi
2004-12-15 17:55 ` Avi Kivity
2004-12-15 21:49 ` Miklos Szeredi
2004-12-03 22:07 ` Daniel Phillips
2004-12-15 17:45 ` Avi Kivity
2004-12-01 7:16 ` Jan Hudec
2004-12-01 13:35 ` Miklos Szeredi
2004-11-30 21:54 ` Pavel Machek
2004-11-18 18:21 ` Miklos Szeredi
2004-11-18 18:31 ` Linus Torvalds
2004-11-18 18:56 ` Miklos Szeredi
2004-11-18 19:16 ` Linus Torvalds
2004-11-18 19:33 ` Miklos Szeredi
2004-11-18 19:43 ` Linus Torvalds
2004-11-18 20:05 ` Miklos Szeredi
2004-11-18 21:06 ` Andrew Morton
2004-11-18 21:33 ` Miklos Szeredi
2004-11-19 11:27 ` Miklos Szeredi
2004-11-27 17:07 ` Rik van Riel
2004-11-27 17:13 ` Pavel Machek
2004-12-03 22:07 ` Daniel Phillips
2004-11-18 20:16 ` Elladan
2004-11-18 18:28 ` Jamie Lokier
2004-11-18 18:47 ` Linus Torvalds
2004-11-18 19:12 ` Bryan Henderson
2004-11-18 19:51 ` Miklos Szeredi
2004-11-18 22:00 ` Jan Hudec [this message]
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=20041118220002.GI2870@vagabond \
--to=bulb@ucw.cz \
--cc=akpm@osdl.org \
--cc=hbryan@us.ibm.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=pavel@ucw.cz \
--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 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).