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

Miklos Szeredi
2004-11-30T21:59:22Z

> 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