Weekly Edition
Return to the Kernel page
| |||||||||||||
Quotes of the week
Well the purpose of the kernel isn't to provide an idiot filter,
that is what the security policies and not giving people root is
for.
-- Alan Cox
The lesson learnt here? Panic makes for poor decisions. I sent one
patch what looked great at the time but have found out in the last
few hours that it really sucks. While figuring this out for sure, I
have to wait looking at a screen to painfully slowly update. To
help the waiting, I found some beer, it's the Irish thing to
do. Wonder what the rest of ye do.
-- Mel
Gorman
Or to say in a more sarcastic way: the most visible effect the
extra code you have to write for making things OOM-safe will be
that due to higher memory/address space consumption the OOM
situation will be coming earlier then without it.
-- Lennart
Poettering
Yes, I realize it's ugly voodoo magic but dammit, it used to work!
-- Pekka Enberg(Log in to post comments)
Quotes of the week Posted Nov 28, 2009 21:13 UTC (Sat) by oak (subscriber, #2786) [Link]
Lennart's whole mail on why and when not to handle allocation
failure "gracefully" is quite good.
Quotes of the week Posted Nov 28, 2009 23:54 UTC (Sat) by nix (subscriber, #2304) [Link]
Exactly. *If* you test these things (look e.g. at sqlite for a clue as to
just how hard that is), then that's one thing. If you don't have a malloc() that can inject OOM on demand, and don't use it to force your allocations to fail individually, then error-checking them is pretty much a waste of time, at least if you do anything but quit. (I *have* found that reporting which allocation failed can be useful in cases where a bug leads to runaway allocation. But there's still little point doing anything but exit(1) afterwards. Let some higher layer in a monitoring process or something like that handle recovery.)
|
|||||||||||||