Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262376AbUK3XBv (ORCPT ); Tue, 30 Nov 2004 18:01:51 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262382AbUK3W73 (ORCPT ); Tue, 30 Nov 2004 17:59:29 -0500 Received: from [194.90.79.130] ([194.90.79.130]:63758 "EHLO argo2k.argo.co.il") by vger.kernel.org with ESMTP id S262394AbUK3W5x (ORCPT ); Tue, 30 Nov 2004 17:57:53 -0500 Message-ID: <41ACFAE7.2050002@argo.co.il> Date: Wed, 01 Dec 2004 00:57:43 +0200 From: Avi Kivity User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041027 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miklos Szeredi 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 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> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Nov 2004 22:57:48.0375 (UTC) FILETIME=[031B7670:01C4D730] Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1478 Lines: 41 Miklos Szeredi wrote: >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? > > > 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. you may also have a hard time with mmap. 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. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - 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/