Hi David. On Tue, Jan 27, 2009 at 01:37:55AM -0800, David Rientjes (rientjes@xxxxxxxxxx) wrote: > > /dev/mem_notify is a great idea, but please do not limit existing > > oom-killer in its ability to do the job and do not rely on application's > > ability to send a SIGKILL which will not kill tasks in unkillable state > > contrary to oom-killer. > > > > You're missing the point, /dev/mem_notify would notify userspace of lowmem > situations and allow it to respond appropriately in any number of ways > before an oom condition exists. Yes, I know. > When the system (or cpuset, memory controller, etc) is oom, userspace can > choose to defer to the oom killer so that it may kill a task that would > most likely lead to future memory freeing with access to memory reserves. > > There is no additional oom killer limitation imposed here, nor can the oom > killer kill a task hung in D state any better than userspace. Well, oom-killer can, since it drops unkillable state from the process mask, that may be not enough though, but it tries more than userspace. My main point was to haev a way to monitor memory usage and that any process could tune own behaviour according to that information. Which is not realated to the system oom-killer at all. Thus /dev/mem_notify is interested first (and only the first) as a memory usage notification interface and not a way to invoke any kind of 'soft' oom-killer. Application can do whatever it wants of course including killing itself or the neighbours, but this should not be forced as a usage policy. -- Evgeniy Polyakov _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
