Messages in this thread |  | | From | Zhaoyang Huang <> | Date | Tue, 10 Apr 2018 08:32:56 +0800 | Subject | Re: [PATCH v1] ringbuffer: Don't choose the process with adj equal OOM_SCORE_ADJ_MIN |
| |
On Mon, Apr 9, 2018 at 9:49 PM, Steven Rostedt <rostedt@goodmis.org> wrote: > On Mon, 9 Apr 2018 08:56:01 +0800 > Zhaoyang Huang <huangzhaoyang@gmail.com> wrote: > >> >> >> >> if (oom_task_origin(task)) { >> >> points = ULONG_MAX; >> >> goto select; >> >> } >> >> >> >> points = oom_badness(task, NULL, oc->nodemask, oc->totalpages); >> >> if (!points || points < oc->chosen_points) >> >> goto next; >> > >> > And what's wrong with that? >> > >> > -- Steve >> I think the original thought of OOM is the flag 'OOM_SCORE_ADJ_MIN' is >> most likely to be set by process himself via accessing the proc file, >> if it does so, OOM can select it as the victim. except, it is >> reluctant to choose the critical process to be killed, so I suggest >> not to set such heavy flag as OOM_SCORE_ADJ_MIN on behalf of -1000 >> process. > > Really, I don't think tasks that are setting OOM_CORE_ADJ_MIN should be > allocating a lot of memory in the kernel (via ring buffer). It sounds > like a good way to wreck havoc on the system. > > It's basically saying, "I'm going to take up all memory, but don't kill > me, just kill some random user on the system". > > -- Steve Sure, but the memory status is dynamic, the process could also exceed the limit at the moment even it check the available memory before. We have to add protection for such kind of risk. It could also happen that the critical process be preempted by another huge memory allocating process, which may cause insufficient memory when it schedule back.
|  |