On Tue, May 20, 2008 at 04:28:16PM -0700, Andrew Morton (akpm@xxxxxxxxxxxxxxxxxxxx) 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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
