yes, that will work. wil need to be extra-careful when one fuse is loopback-mounted on another.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.
I'm no mmap expert. but doesn't writing to a mmaped page have to increase your dirty counter somehow?
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 think this is a good summary.
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.