Messages in this thread | | | From | "Stephen C. Tweedie" <> | Date | Mon, 6 Mar 2000 22:53:26 +0000 (GMT) | Subject | Re: 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/
| |