Messages in this thread | | | From | KOSAKI Motohiro <> | Subject | Re: [PATCH v2]mm/oom-kill: direct hardware access processes should get bonus | Date | Tue, 23 Nov 2010 16:16:57 +0900 (JST) |
| |
> 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.
| |