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. 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(). > > > 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. -- 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>