Re: [patch] memcg: add oom killer delay

[David Rientjes <rientjes@google.com>]

On Thu, 3 Mar 2011, Andrew Morton wrote:

> If userspace has chosen to repalce the oom-killer then userspace should
> be able to appropriately perform the role.  But for some
> as-yet-undescribed reason, userspace is *not* able to perform that
> role.
> 
> And I'm suspecting that the as-yet-undescribed reason is a kernel
> deficiency.  Spit it out.
> 

The purpose of memory.oom_control is to disable to kernel oom killer from 
killing a task as soon as a memcg reaches its hard limit and reclaim has 
failed.  We want that behavior, but only temporarily for two reasons:

 - the condition may be temporary and we'd rather busy loop for the 
   duration of the spike in memory usage than kill something off because 
   it will be coming under the hard limit soon or userspace will be 
   increasing that limit (or killing a lower priority job in favor of 
   this one), and

 - it's possible that the userspace daemon is oom itself (being in a 
   separate cgroup doesn't prevent that) and is therefore subject to 
   being killed itself (or panicking the machine if its OOM_DISABLE and 
   nothing else is eligible) and cannot rectify the situation in other 
   memcgs that are also oom.

So this patch is not a bug fix, it's an enhancement to an already existing 
feature (memory.oom_control) that probably should have been coded to be a 
timeout in the first place and up to userspace whether that's infinite or 
not.

Not merging this patch forces us into the very limiting position where we 
either completely disable the oom killer or we don't and that's not 
helpful in either of the above two cases without relying on userspace to 
fix it (and it may be oom itself and locked out of freeing any memory via 
the oom killer for the very same reason).

So the question I'd ask is: why should the kernel only offer a complete 
and infinite disabling of the oom killer (something we'd never want to do 
in production) to allow userspace a grace period to respond to reaching 
the hard limit as opposed to allowing users the option to allow the 
killing iff userspace can't expand the cgroup or kill something itself.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>