"DeRobertis" <derobert@erols.com> said:
> At 4:20 PM -0400 on 3/13/00, Horst von Brand wrote:
> >"DeRobertis" <derobert@erols.com> said:
> >[...]
> >> I'll bring back up memory priorities here... they would solve this.
> >> They're exactly what you're asking for. And someday hopefully I'll have
> >> the time to write the code :)
> >Sorry to rain on the parade... but we are talking about absolutely
> >exceptional situations here (OOM), and nobody will sit down and tweak
> >"memory priorities" for the tasks that might be running when OOM, and even
> >less come up with a sensible set of priorities the first round.
> Some of us will. And (reasonably) sensible ones can be by default:
>
> init, syslogd, very important stuff -20
"very important stuff" is a very wide term... it will end up being "all
root processes", and that is (essentially) square one.
> root logins -15
How do you know it is a root login, and not Jane Random Luser?
> certain important commands when run as -10
> root (e.g., kill, ps, top)
"certain important commands" is again a very wide term...
> demons -5
> user-level 0
> user cron & at jobs 5
> The memory priorities could also be extended to general resource
> priorities, such as process limits. With the examples above, assume
> some group of rogue users are running ridiculously large programs which
> span like crazy. If root tries to log in, there will be no resources to
> do so. To free some up, the kernel would start killing first user cron
> & at jobs, then general user-level jobs, then demons. It'd stop when
> possible.
Those cron/at jobs might very well be much more important that the random
httpd which just exploded, or Joe Random's mp3 player.
> One important thing to note is that ther kernel would not have these
> defaults built in -- they would be taken by processes in the normal
> manner; root processes only can decrease their priority numbers while
> any process can increase its priority number.
Note the nice(1) man page, which traditionally says something like: "Bugs:
Nobody uses it"
In any case, your VM priorities _must_ be tied to niceness, it makes no
sense to have a high-level VM priority on a process that never gets to
run. And, AFAIU this is what Rik's patch does on itself...
And, yet again (it must be around a dozen times now): OOM is an extremely
exceptional condition, absolutely *NO* extra effort should be expended on
solving just this problem.
-- Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513- 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.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:18 EST