![]() | ||||||||||
Messages in this thread |
Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz> wrote: > > >> I liked what linux-2.0 did in this case --- if the kernel was out of > >> memory, getblk just took another buffer, wrote it if it was dirty and used > >> it. Except for writeable loopback device (where writing one buffer > >> generates more dirty buffers), it couldn't deadlock. > > > > Wouldn't it be better if bread() were to return ERR_PTR(-EIO) or > > ERR_PTR(-ENOMEM)? Big change. > > No. Out of memory condition can happen even under normal circumstances > under lightly loaded system. Think of a situation when dirty file-mapped > pages fill up the whole memory, now a burst of packets from network comes > that fills up kernel atomic reserve, you have zero pages free --- and what > now? --- returning ENOMEM and dropping dirty pages without writing them is > wrong, deadlocking (filesystem waits until memory manager frees some pages > and memory manager waits until filesystem writes the dirty pages) is wrong > too. Well. The filesystem could just redirty the page and skip the writepage(). That's still deadlockable but I bet the kernel would recover in the vast majority of cases. Still, this is all very theoretical - there are no plans to make getblk bail out on oom - AFAIK nobody has been able to demonstrate a testcase... - 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/ | |||||||||
| Last update: 2005-10-11 03:06 [W:0.403 / U:0.200 seconds] ©2003-2008 Jasper Spaans | ||||||||||