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.
The filesystem must make sure that it doesn't need any memory to do block
allocation and data write. Linux-2.0 got this right, it could do getblk
and bread even if get_free_pages constantly failed.
Mikulas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
