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

[Avi Kivity]

(with apologies for the long delay)

Miklos Szeredi wrote:

> > If you plan on partitioning system memory into none-fuse and fuse 
> > memory, yes, that could work. but it's horribly inflexible - right now 
> > memory is balanced dynamically according to actual use. 
> >    
>
> No partitioning is needed.  If fuse doesn't consume too much memory
> for dirty data buffers that memory is free to use for other purposes.
>
> But fuse would be limited in the number of pages which it can use for
> dirty buffers exactly to prevent it from causing OOM.
>  
yes, that will work. wil need to be extra-careful when one fuse is 
loopback-mounted on another.

I'm concerned that you're duplicating all the accounting done currently, 
and all of the writeback logic that is dependent on the number of dirty 
pages.

an additional concern is a fuse/non-fuse mix - how do you balance them out?

with a single accounting it happens naturally.

>  
>
> > you may also have a hard time with mmap.
> >    
>
> What sort?  You can mmap a 4G file on a machine with 32M memory.  More
> memory can improve performance, of course, but otherwise the amount of
> memory doesn't matter.
>  
I'm no mmap expert. but doesn't writing to a mmaped page have to 
increase your dirty counter somehow?

>  
>
> > my proposal (with the per-process allocation thredsholds) only reserves 
> > a small amount of memory to the fuse(s), with the rest allocated 
> > dynamically using the normal kernel policies, with no special 
> > restrictions on fuse.
> >    
>
> Yes, but what you reserve (which may be large for some filesystems) is
> totally unusable memory except in the special case of helping writeout
> in low memory situation, while in my solution the rest of the system
> is not limited only the fuse filesystem.
>
> There's not that much difference between what we are saying, but as I
> said, I detest the thought, that the filesystem process has to be
> special, and I'm prepared to give up some flexibility and performance
> for this.
>  
I think this is a good summary.

--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

-
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/