lkml.org 
[lkml]   [2000]   [Mar]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Overcommitable memory??
Date
From
Jesse Pollard <pollard@cats-chateau.net> said:

[...]

> What waas offerred is not overcommit - a limited reserve allocation, not
> the entire process.

This is either-or. No "a bit overcommitted is OK", it _could_ lead to
processes dying at random, which you aren't tolerating.

[...]

> The cost to current hardware is under .5 %. The actual code is mostly there
> now, it just checks against the catastrophic condition instead of checking
> agains a users quota.

The infrastructure you are talking about just doesn't exist _at all_ (if it
was extant, this discussion wouldn't be taking place at all), so your 0.5%
is at best a crude guess. If you are counting the cost of Rik's patch,
expanding this to a full-blown user quota system means:

- Set up a data structure for keeping track of user's allowances, using up
RAM
- Adjust it each time said user does something. Note that most of the ideas
for accounting shared resources that have been discussed here (divide the
size of code segments among users, for instance) does need extra
processing _for each current user_, and possibly extra infrastructure
that just isn't there now

This doesn't sound like 0.5% of what the kernel does right now to me...
--
Horst von Brand vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Viña del Mar, Chile +56 32 672616

-
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.213 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site