> Date: Sun, 16 Aug 1998 08:19:36 -0400 (EDT)
> From: "Stephen M. Benoit" <benoits@servicepro.com>
>
> Am I missing the point? I was under the impression that there is a
> well-defined behavior when a Un*x reaches memory resource limits.
> Additional requests for resources are simply denied: currently
> executing processes don't get axed until they segfault, get signalled
> or exit().
---<snip>---
> The problem with using stract allocation is that you will start
> returning ENOMEM while there is still plenty of memory available, since
> most of the time the maximum theoretical memory that might be used by a
> process (if you have to allocate pages for all of itw COW pages, etc.)
> is nil. For example, if you have a huge executable, but the way you use
> the program, most of it never gets used, a strict allocation system
> might not let you run the executable, even though there might be plenty
> of space and no problems since the executable might not use all of its
> text pages (especially true with shared libraries). Strict allocation
> demands that you reserve a page for each processes's use of a text or
> shared library memory page, since there's a chance it might get
> duplicated because of debugger setting a break point (for example).
Ouch! Conditional memory malloc()s are the worst. I see your
point. It's not as deterministic as I originally suggested.
---<snip>---
> I've tried using a system with strict allocation, and it runs out of
> memory *really* quickly. In fact, it usually runs out of memory so
> quickly that it's frequently not very useful.
I can see why it's a balancing act.
Okay, this is a classic problem in the airline industry. More
seats are sold than there were seats on the plane. The reasoning
is that overbooking ensures full planes since lots of people
cancel or don't show up. When too many people show up for their
flight, some lucky bunch get a bonus for choosing another flight.
I guess the analogy breaks when you only realize that the plane is
over-capacity during takeoff. :-O
I'm still not comfortable with `init' running /sbin/grim_reaperd to
kill some so that others may survive. There's a chance that
/bin/heart_lung_ctrl and /sbin/plant_safety could be axed while
/usr/bin/X11/xeyes is left standing.
Perhaps we need an additional `survival' priority in task_struct to
make the choices easier. While some processes can be nice()'d to
reduce scheduling priority, it might be useful to deathwish() the
less-vital processes. Of course, only root would be able to select
deathwish(-20).
Would this ever find its way into POSIX? I won't hold my breath ;-)
_____________________________ Stephen M. Benoit _______________________________
~ ~ | benoits@servicepro.com | B.Eng (Computer), M.Eng (Electrical)
('>') | Tel: +1 514 255-3550 | Service Providers of America INC
_ | FAX: +1 514 256-1356 | Web page: http://www.servicepro.com/
_______|________________________|______________________________________________
-
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.altern.org/andrebalsa/doc/lkml-faq.html