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

[Bryan Henderson]

>> A normal write is a VFS write() call, I assume.  While they're going 
>> through the page cache, the pages are dirty, right?  Is it possible 
that 
>> FUSE needs more real memory after dirtying those pages in order to 
finish 
>> cleaning them?
>
>It's possible, but I don't see why that's a problem.  If it can get
>more memory it's OK.  If allocation fails, then the write() will fail
>with ENOMEM, if OOM killer get's to work and kills the FUSE process,
>then write will return with ENOTCONN or something like that.

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.

I don't see where in this path the write() has a chance to fail.

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.

--
Bryan Henderson                          IBM Almaden Research Center
San Jose CA                              Filesystems
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/