lkml.org 
[lkml]   [2000]   [Mar]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Some questions about linux kernel.
Date
From
"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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.122 / U:0.352 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site