Re: [patch -mm 01/18] oom: filter tasks not sharing the same cpuset

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, 13 Jun 2010, KOSAKI Motohiro wrote:

> I have no objection because it's policy matter. but if so, dump_tasks()
> should display mem_allowed mask too, probably.

You could, but we'd want to do that all under cpuset_buffer_lock so we 
don't have to allocate it on the stack, which can be particularly lengthy 
when the page allocator is called.

> > >   (3) oom_kill_task (when oom_kill_allocating_task==1 only)
> > > 
> > 
> > Why would care about cpuset attachment in oom_kill_task()?  You mean 
> > oom_kill_process() to filter the children list?
> 
> Ah, intersting question. OK, we have to discuss oom_kill_allocating_task
> design at first.
> 
> First of All, oom_kill_process() to filter the children list and this issue
> are independent and unrelated. My patch was not correct too.
> 
> Now, oom_kill_allocating_task basic logic is here. It mean, if oom_kill_process()
> return 0, oom kill finished successfully. but if oom_kill_process() return 1,
> fallback to normall __out_of_memory().
> 

Right.

> 
> 	===================================================
> 	static void __out_of_memory(gfp_t gfp_mask, int order, nodemask_t *nodemask)
> 	{
> 	        struct task_struct *p;
> 	        unsigned long points;
> 	
> 	        if (sysctl_oom_kill_allocating_task)
> 	                if (!oom_kill_process(current, gfp_mask, order, 0, NULL, nodemask,
> 	                                      "Out of memory (oom_kill_allocating_task)"))
> 	                        return;
> 	retry:
> 
> When oom_kill_process() return 1?
> I think It should be
> 	- current is OOM_DISABLE

In this case, oom_kill_task() returns 1, which causes oom_kill_process() 
to return 1 if current (and not one of its children) is actually selected 
to die.

> 	- current have no intersected CPUSET

current will always intersect its own cpuset's mems.

> 	- current is KTHREAD

find_lock_task_mm() should take care of that in oom_kill_task() just like 
it does for OOM_DISABLE, although we can still race with use_mm(), in 
which case this would be a good chance.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]