Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261169AbUKRVDE (ORCPT ); Thu, 18 Nov 2004 16:03:04 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261208AbUKRVA6 (ORCPT ); Thu, 18 Nov 2004 16:00:58 -0500 Received: from fw.osdl.org ([65.172.181.6]:58043 "EHLO mail.osdl.org") by vger.kernel.org with ESMTP id S261167AbUKRU5z (ORCPT ); Thu, 18 Nov 2004 15:57:55 -0500 Date: Thu, 18 Nov 2004 12:57:34 -0800 From: Andrew Morton To: Linus Torvalds Cc: alan@lxorguk.ukuu.org.uk, miklos@szeredi.hu, hbryan@us.ibm.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, pavel@ucw.cz Subject: Re: [PATCH] [Request for inclusion] Filesystem in Userspace Message-Id: <20041118125734.32ec8e88.akpm@osdl.org> In-Reply-To: References: <1100798975.6018.26.camel@localhost.localdomain> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1560 Lines: 36 Linus Torvalds wrote: > > > > On Thu, 18 Nov 2004, Alan Cox wrote: > > > > > I really do believe that user-space filesystems have problems. There's a > > > reason we tend to do them in kernel space. > > > > > > But limiting the outstanding writes some way may at least hide the thing. > > > > Possibly dumb question. Is there a reason we can't have a prctl() that > > flips the PF_* flags for a user space daemon in the same way as we do > > for kernel threads that do I/O processing ? > > It's more than just PF_MEMALLOC. > > And PF_MEMALLOC really is to avoid _recursion_, which is the smallest > problem. It does so by allowing the process to dip into the critical > resources, but that only works if you know that the process is actually > freeing pages right then and there. If you set it willy-nilly, you'll just > run out of pages soon, and you'll be dead. I've seen one 2.4-based project which had essentially a userspace blockdevice driver. Marking that special, trusted process PF_MEMALLOC did indeed fix low-on-memory deadlocks. Obviously it's something one does with caution, but there are times when it makes sense. I think there are codepaths which unconditionally turn off PF_MEMALLOC, so they need to be tweaked to do a save/set/restore operation for it all to work. - 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/