On Tue, 2010-11-09 at 13:06 -0800, David Rientjes wrote: > On Tue, 9 Nov 2010, Alan Cox wrote: > > > The reverse can be argued equally - that they can unprotect themselves if > > necessary. In fact it seems to be a "point of view" sort of question > > which way you deal with CAP_SYS_RESOURCE, and that to me argues that > > changing from old expected behaviour to a new behaviour is a regression. > > > > I didn't check earlier, but CAP_SYS_RESOURCE hasn't had a place in the oom > killer's heuristic in over five years, so what regression are we referring > to in this thread? These tasks already have full control over > oom_score_adj to modify its oom killing priority in either direction. yes, it can control by user, but is it all system administrators will adjust all of the processes by each one and one in real word? suppose if it has thousands of processes in database system. > Futhermore, the heuristic was entirely rewritten, but I wouldn't consider > all the old factors such as cputime and nice level being removed as > "regressions" since the aim was to make it more predictable and more > likely to kill a large consumer of memory such that we don't have to kill > more tasks in the near future. the goal of oom_killer is to find out the best process to kill, the one should be: 1. it is a most memory comsuming process in all processes 2. and it was a proper process to kill, which will not be let system into unpredictable state as possible. if a user process and a process such email cleint "evolution" with ditecly hareware access such as "Xorg", they have eat the equal memory, so which process are you want to kill? -- 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>