[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080521061531.GA27362@2ka.mipt.ru>
Date: Wed, 21 May 2008 10:15:32 +0400
From: Evgeniy Polyakov <johnpol@....mipt.ru>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: David Chinner <dgc@....com>, Christoph Lameter <clameter@....com>,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
Mel Gorman <mel@...net.ie>, andi@...stfloor.org,
Rik van Riel <riel@...hat.com>,
Pekka Enberg <penberg@...helsinki.fi>, mpm@...enic.com
Subject: Re: [patch 10/21] buffer heads: Support slab defrag
On Tue, May 20, 2008 at 04:28:16PM -0700, Andrew Morton (akpm@...ux-foundation.org) wrote:
> It's more than efficiency. There are lots and lots of things we cannot
> do in direct-reclaim context.
>
> a) Can't lock pages (well we kinda sorta could, but generally code
> will just trylock)
>
> b) Cannot rely on the inode or the address_space being present in
> memory after we have unlocked the page.
>
> c) Cannot run iput(). Or at least, we couldn't five or six years
> ago. afaik nobody has investigated whether the situation is now
> better or worse.
>
> d) lots of deadlock scenarios - need to test __GFP_FS basically everywhere
> in which you share code with normal writeback paths.
>
> Plus e), f), g) and h). Direct-reclaim is a hostile environment.
> Things like b) are a real killer - nasty, subtle, rare,
> memory-pressure-dependent crashes.
Which basically means we can not do direct writeback at reclaim time?..
--
Evgeniy Polyakov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists