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@xxxxxxxxxx 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@xxxxxxxxx";> email@xxxxxxxxx </a>