> On Mon, 15 Nov 2010, KOSAKI Motohiro wrote: > > > > I think in cases of heuristics like this where we obviously want to give > > > some bonus to CAP_SYS_ADMIN that there is consistency with other bonuses > > > given elsewhere in the kernel. > > > > Keep comparision apple to apple. vm_enough_memory() account _virtual_ memory. > > oom-killer try to free _physical_ memory. It's unrelated. > > > > It's not unrelated, the LSM function gives an arbitrary 3% bonus to > CAP_SYS_ADMIN. Unrelated. LSM _is_ security module. and It only account virtual memory. > Such threads should also be preferred in the oom killer > over other threads since they tend to be more important but not an overly > drastic bias such that they don't get killed when using an egregious > amount of memory. So in selecting a small percentage of memory that tends > to be a significant bias but not overwhelming, I went with the 3% found > elsewhere in the kernel. __vm_enough_memory() doesn't have that > preference for any scientifically calculated reason, it's a heuristic just > like oom_badness(). __vm_enough_memory() only gurard to memory overcommiting. And it doesn't have any recover way. We expect admin should recover their HAND. In the other hand, oom-killer _is_ automatic recover way. It's no need admin's hand. That's the reason why CAP_ADMIN is important or not. > > > > CAP_SYS_RAWIO mean the process has a direct hardware access privilege > > > > (eg X.org, RDB). and then, killing it might makes system crash. > > > > > > > > > > Then you would want to explicitly filter these tasks from oom kill just as > > > OOM_SCORE_ADJ_MIN works rather than giving them a memory quantity bonus. > > > > No. Why does userland recover your mistake? > > > > You just said killing any CAP_SYS_RAWIO task may make the system crash, so > presuming that you don't want the system to crash, you are suggesting we > should make these threads completely immune? That's never been the case > (and isn't for oom_kill_allocating_task, either), so there's no history > you can draw from to support your argument. No. I only require YOU have to investigate userland usecase BEFORE making change. -- 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>