From: Daniel Phillips <phillips@istop.com>
To: Andrew Morton <akpm@osdl.org>
Subject: Re: [PATCH] [Request for inclusion] Filesystem in Userspace
Date: Wed, 24 Nov 2004 01:20:40 -0500
User-Agent: KMail/1.7
Cc: Linus Torvalds <torvalds@osdl.org>, 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
References: <OF28252066.81A6726A-ON88256F50.005D917A-88256F50.005EA7D9@us.ibm.com> <Pine.LNX.4.58.0411181047590.2222@ppc970.osdl.org> <20041118125734.32ec8e88.akpm@osdl.org>
In-Reply-To: <20041118125734.32ec8e88.akpm@osdl.org>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200411240120.40820.phillips@istop.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1023
Lines: 26

Hi Andrew,

On Thursday 18 November 2004 15:57, Andrew Morton wrote:
> 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.

Like the cluster stack, unless we're happy with inhaling all the membership, 
failover, fencing and etc code into the kernel.

> 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.

The only one I spotted is in dm-ioctl.c.  We get away with the one in 
page_alloc.c by branching around it in PF_MEMALLOC mode.

Regards,

Daniel
-
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/