Re: [PATCH] [Request for inclusion] Filesystem in Userspace

[Jan Hudec]

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@xxxxxx>

Attachment: signature.asc
Description: Digital signature