Messages in this thread | | | Date | Wed, 5 Aug 2009 11:40:04 +0900 | From | Minchan Kim <> | Subject | Re: [PATCH 1/4] oom: move oom_adj to signal_struct |
| |
On Wed, 5 Aug 2009 11:29:34 +0900 (JST) KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote:
> Hi > > > Hi, Kosaki. > > > > I am so late to invole this thread. > > But let me have a question. > > > > What's advantage of placing oom_adj in singal rather than task ? > > I mean task->oom_adj and task->signal->oom_adj ? > > > > I am sorry if you already discussed it at last threads. > > Not sorry. that's very good question. > > I'm trying to explain the detailed intention of commit 2ff05b2b4eac > (move oom_adj to mm_struct). > > In 2.6.30, OOM logic callflow is here. > > __out_of_memory > select_bad_process for each task > badness calculate badness of one task > oom_kill_process search child > oom_kill_task kill target task and mm shared tasks with it > > example, process-A have two thread, thread-A and thread-B and it > have very fat memory. > And, each thread have following likes oom property. > > thread-A: oom_adj = OOM_DISABLE, oom_score = 0 > thread-B: oom_adj = 0, oom_score = very-high > > Then, select_bad_process() select thread-B, but oom_kill_task refuse > kill the task because thread-A have OOM_DISABLE. > __out_of_memory() call select_bad_process() again. but select_bad_process() > select the same task. It mean kernel fall in the livelock. > > The fact is, select_bad_process() must select killable task. otherwise > OOM logic go into livelock. > > Is this enough explanation? thanks. >
Thanks for good explanation. :)
It resulted from patch of David which moved task_struct->oom_ajd to mm_struct. I understood it.
It meant oom_adj was not per-process.
AFAIU, you want to make oom_adj per-process, again. And you selected the place with task->singal as per-process.
What I have a question is that why do you select task_struct->signal rather than task_struct like old?
What's benefit of using task_struct->signal ?
-- Kind regards, Minchan Kim
| |