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

[Miklos Szeredi]

> Looks like we are in a deadlock here :)
> 
> However you choose to call it, it is unacceptable IMO.

That I can agree with.  I never said that this was a full solution,
only that this shows, that the deadlock is not inherent in userspace
filesystems.

> So the userspace filesystem would pass that amount to the kernel. It's 
> not pretty, but it is workable.

Not pretty is an understatement IMO.

> >And this is not unique to userspace filesystems, as Rik van Riel
> >pointed out earlier, network filesystems are also prone to deadlock:
> >
> >http://lkml.org/lkml/2004/11/27/81
> >
> >  
> >
> This looks like a bug to me. Maybe jiggling the thresholds would help.

Yes, and it's the jiggling I want to avoid.

> The situation with userspace filesystems is:
> 
>   some process allocates memory, blocking on kswapd as memory is full
>   kswapd calls userspace filesystem to free memory
>   userspace filesystem calls kernel, which allocates memory and blocks 
> on kswapd
>   eventually all processes in the system block on kswapd
> 
> I have observed (and fixed) this on a real system.

I have observed it too (not yet fixed, but working on it).  But
realize that my proposal would excempt userspace filesystem pages from
being blocked on by kswapd.  That's a fundamental difference.

Since you don't believe me, I'll have to make an implementation, so
you can experiment with it.  And if you'll still be able to cause a
deadlock, I'll subject myself to extreme repentance, and promise never
to touch an operating system ever again :)

> with ramfs, once it accounts for memory, there would be no deadlock and 
> no oom.

And once fuse acounts for memory there will be no deadlock and no oom.
See the symmetry?

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