On Tue, 2 Nov 2010, Figo.zhang wrote: > > Which applications are you referring to that cannot gracefully exit if > > killed? > > like Xorg server, if xorg server be killed, the gnome desktop will be > crashed. > Right, but you didn't explicitly prohibit such applications from being killed, so that suggests that doing so may be inconvenient but doesn't incur something like corruption or data loss, which is what I would consider "unstable" or "inconsistent" state. We're trying to avoid any additional heuristics from being introduced for specific usecases, even for Xorg. That ensures that the heuristic remains as predictable as possible and frees a large amount of memory. If Xorg is being killed first instead of a true memory hogger, then it seems like a forkbomb scenario instead; could you please post your kernel log so that we can diagnose that issue seperately? > > CAP_SYS_RAWIO had a much more dramatic impact in the previous heuristic to > > such a point that it would often allow memory hogging tasks to elude the > > oom killer at the expense of innocent tasks. I'm not sure this is the > > best way to go. > > is it some experiments for demonstration the CAP_SYS_RAWIO will elude > the oom killer? > The old heuristic would allow it to elude the oom killer because it would divide the score by four if a task had the capability, which is a much more drastic "bonus" than you suggest here. That would reduce the score for the memory hogging task significantly enough that we killed tons of innocent tasks instead before eventually killing the task that was leaking memory but failed to be identified because it had CAP_SYS_RAWIO. I'm trying to avoid any such repeats. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>