Messages in this thread | | | From | Vaibhav Nagarnaik <> | Date | Mon, 30 May 2011 16:46:52 -0700 | Subject | Re: [PATCH] trace: Set oom_score_adj to maximum for ring buffer allocating process |
| |
On Fri, May 27, 2011 at 6:50 PM, Steven Rostedt <rostedt@goodmis.org> wrote: > On Fri, 2011-05-27 at 17:44 -0700, Vaibhav Nagarnaik wrote: > >> That said, I am open to changing it if Steven and you think using >> oom_killer_disabled is a better solution. > > My biggest concern is that we are setting policy in the kernel. If you > are concerned about this, why not just have the process that is going to > increase the size of the ring buffer adjust its own oom policy > with /proc/<pid>/oom_score_adj ? Only a privilege process can increase > the size of the ring buffer so it's not like we are worried about any > normal user task upping the ring buffer to kill other processes. > > -- Steve
You are right. Changing the value of oom_killer_disabled is setting kernel policy and I don't like the solution either.
It would be great if the user always sets oom_score_adj while allocating ring buffer memory, but there are different use cases I see where it might not be feasible. One is the number of different applications which use ftrace and set the ring buffer memory size (trace-cmd, perf, powertop, etc). The other case is where a developer is setting the size for his own tracing. In all these cases, oom_score_adj *should* be set to maximum to be safe, but it a developer might forget this step and can de-stabilize the system. This is why I think that setting oom_score_adj to maximum in the kernel while allocating buffer as well as using __GFP_NORETRY should suffice for the end goal of being a good memory citizen.
Vaibhav Nagarnaik
| |