Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261233AbUK3V7W (ORCPT ); Tue, 30 Nov 2004 16:59:22 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261274AbUK3V7V (ORCPT ); Tue, 30 Nov 2004 16:59:21 -0500 Received: from rev.193.226.233.139.euroweb.hu ([193.226.233.139]:63616 "EHLO dorka.pomaz.szeredi.hu") by vger.kernel.org with ESMTP id S261233AbUK3V7N (ORCPT ); Tue, 30 Nov 2004 16:59:13 -0500 To: avi@argo.co.il CC: alan@lxorguk.ukuu.org.uk, torvalds@osdl.org, hbryan@us.ibm.com, akpm@osdl.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, pavel@ucw.cz In-reply-to: <41ACE816.50104@argo.co.il> (message from Avi Kivity on Tue, 30 Nov 2004 23:37:26 +0200) Subject: Re: [PATCH] [Request for inclusion] Filesystem in Userspace References: <1100798975.6018.26.camel@localhost.localdomain> <41A47B67.6070108@argo.co.il> <41ACBF87.4040206@argo.co.il> <41ACD03C.9010300@argo.co.il> <41ACE816.50104@argo.co.il> Message-Id: From: Miklos Szeredi Date: Tue, 30 Nov 2004 22:58:49 +0100 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1969 Lines: 55 > 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/