lkml.org 
[lkml]   [2002]   [Sep]   [12]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
FromTim Connors <>
SubjectRe: Killing/balancing processes when overcommited
DateThu, 12 Sep 2002 17:06:27 +1000
In linux.kernel, you wrote:
> 
>                                     resource
>      group                          priority                kill priority
>      system                         0                       0 - never kill
>      support                        1                       1
>      payroll                        2                       2
>      production                     3                       3
>      general user                   4                       4
>      production backgournd    5           3   <- make sure testing and
> general user are killed BEFORE production
>      testing                        6                       5
> 
> Note that in the example above, production has the second lowest resource
> priority, but a higher kill priority ("we don't care how long it takes, but
> it must complete").
> 
> In a system with sufficient resources, everyone would get what they needed.
> As resources become limit, payroll gets resources first and testing gets
> the least. In the extreme case, when the system is overwhelmed, testing is
> the first to be removed.

You seemed to have just described a combination of forced niceness
(from login scripts) and ulimit. Man ulimit about how to limit number
of processes plus memory etc, so people can't fork() bomb you out of
existance.

-- 
TimC -- http://astronomy.swin.edu.au/staff/tconnors/

Conclusion to my thesis -- 
"It is trivial to show that it is clearly obvious that this is not 
woofly"

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:28    [from the cache]
©2003-2008