lkml.org 
[lkml]   [2000]   [Mar]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: Linux 2.2.15pre12
Hi,

On Fri, 3 Mar 2000 17:33:06 +0000 (GMT Standard Time), Paul Jakma
<paul.jakma@compaq.com> said:
> just wondering, could linux implement a 'hard' memory alloc policy? a la
> solaris/Tru64/and probably many other unices.. ie when memory is
> allocated to an app, it's /guaranteed/ to be there?

It doesn't really help. You can implement it, sure, but only by
returning an unconditional ENOMEM if there is any risk of going over
budget.

Your user space app uses all the memory it can and then gets ENOMEM on
the next malloc. Fine.

Then named does a malloc. It gets ENOMEM and dies, and the freed memory
gets gobbled by your memory-hog application. Then inetd does a malloc.
It gets ENOMEM and dies. Then sendmail. Then init.

The gradual (then rapid) performance degradation you get with relaxed
memory committing is, in many ways, *much* better than hard overcommit
rules when it comes to protecting system daemons.

--Stephen

-
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:56    [from the cache]
©2003-2011 Jasper Spaans