Messages in this thread | | | Subject | Re: [PATCH] [Request for inclusion] Filesystem in Userspace | From | Miklos Szeredi <> | Date | Tue, 30 Nov 2004 22:58:49 +0100 |
| |
> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |