> I (as a user) start 20 or 30 processes, and leave them running
> I slowly let them use up enough CPU so that they are the longest lived
> processes on the box, but still among the smallest.
>
> I then do something to cause an OOM, but not kill any of mine, but cause
> some other process to try to allocate memory, and I can kill it.
> We don't want any way to kill syslogd, inetd, update, or numerous
> other tasks, by the average user.
Syslogd, inetd, etc... will not be killed by my solution,
since they are small.
A long-running process can still be killed; for 'normal'
processes, the 'killer points' are calculated this way:
points = size / sqrt(CPU_used in 8 sec increments)
Maybe I should also divide the points by
sqrt(TIME_running in 1 hour increments) so that
long-running processes also get a better score
and are less likely to be killed.
> Is the solution simply to ignore this one, and say "quotas", to weight
> processes with bound reserved ports, and ones by root higher, or a
> list of names never to kill, unless they are seriously out of control.
The reserved ports one is a good point; however, this could
keep the kernel from killing a runaway apache (leaving the
apache parent up and running because it's root).
The list of names is a tricky one; programs can control
the p->comm[] array themselves. This is absolutely needed
to prevent sensitive command line arguments (passwords,
etc) from leaking.
Rik.
+-------------------------------------------------------------------+
| Linux memory management tour guide. H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html