On Mon, Jan 12, 2009 at 04:19:31PM +0000, Alan Cox (alan@xxxxxxxxxxxxxxxxxxx) wrote:The only cases in which this would really be useful is when running some software which once in a great while goes super prompt critical and starts throwing processes of a known name format in all directions, or when you have a problem and know the process names involved before OOM kills everything in sight.Yes, it could be done. If inotify will not be killed itself, will beIt is perfectly soluble right now, use the existing /proc interface. If
enabled in the config and daemon will be started.
But right now there is no way to solve that task, in the long term this
is a good idea to implement modulo security problems it may concern.
you want to specifically victimise new tasks first then set everything
else with an adjust *against* being killed and new stuff will start off
as cannon fodder until classified.
The name approach is the wrong way to handle this. It has no reflection
of heirarchy of process, targetting by users, containers etc..
In fact containers are probably the right way to do it
Containers to solve oom-killer selection problem? :)
Being more serious, I agree that having a simple name does not solve the
problem if observed from any angle, but it is not the main goal.
Patch solves oom-killer selection issue from likely the most commonly
used case: when you know who should be checked and killed first when
problem appears.