Messages in this thread | | | Subject | Re: Some questions about linux kernel. | Date | Thu, 16 Mar 2000 10:28:28 -0400 | From | Horst von Brand <> |
| |
"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/
| |