Messages in this thread | | | Date | Wed, 14 Dec 2011 08:52:36 +0900 | From | KAMEZAWA Hiroyuki <> | Subject | Re: [PATCH v4] oom: add trace points for debugging. |
| |
On Tue, 13 Dec 2011 14:58:51 -0800 Andrew Morton <akpm@linux-foundation.org> wrote:
> On Tue, 13 Dec 2011 18:12:25 +0900 > KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote: > > > Changelog: > > - devided into oom tracepoint and task tracepoint. > > - task tracepoint traces fork/rename > > - oom tracepoint traces modification to oom_score_adj. > > > > dropped acks because of total design changes. > > > > From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> > > Subject: [PATCH] tracepoint: add tracepoints for debugging oom_score_adj. > > > > oom_score_adj is used for guarding processes from OOM-Killer. One of problem > > is that it's inherited at fork(). When a daemon set oom_score_adj and > > make children, it's hard to know where the value is set. > > This sounds like a really thin justification for patching the kernel. > "Help! I don't know what my code is doing!". > > Alternatives would include grepping your source code for > "oom_score_adj", or running "strace -f"! > > I suspect you did have a good reason for making this change, but it > wasn't explained very well? >
Ah, one example is this thread. - http://marc.info/?t=132273239800008&r=1&w=4 oom_score_adj was inherited by sshd by bug?
And IIUC, I saw other issues with other task launchers as Gnome.
If the problem is caused by some daemon, strace -f is not very good. And the user will not have the source codes. So, I thought it's better to have tracepoints to see what is wrong in application chains.
Thanks, -Kame
| |