On Fri, 28 May 2010 11:57:01 +0530
Balbir Singh <balbir@xxxxxxxxxxxxxxxxxx> wrote:
> I am still not convinced, specially if we are running under mem
> cgroup. Even setting SCHED_FIFO does not help, you could have other
> things like cpusets that might restrict the CPUs you can run on, or
> any other policy and we could end up contending anyway with other
> SCHED_FIFO tasks.
>
> > That's the reason I acked it.
>
> If we could show faster recovery from OOM or anything else, I would be
> more convinced.
>
Off topic.
1. Run a daemon in the highest RT priority.
2. disable OOM for a mem cgroup.
3. The daemon register oom-event-notifier of the mem cgroup.
When OOM happens.
4. The daemon receive a event, and then,
a) enlarge limit
or
b) kill a task
or
c) enlarge limit temporary and kill a task, later, reduce limit again.
This is the fastest and promissing operation for memcg users.
memcg's oom slowdown happens just because it's limited by a user configuration
not by the system. That's a point to be considered.
The oom situation can be _immediaterly_ fixed up by enlarge limit as emergency mode.
If you has to wait for the end of a task, there will be delay, it's unavoidable.
Thanks,
-Kame
--
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>