Messages in this thread |  | | | Date | Mon, 27 Mar 2000 09:52:18 +0200 | | From | Helge Hafting <> | | Subject | Re: Endless overcommit memory thread. |
| |
>If an application allocates a large amount of memory and then >does not use it, is the app not broken as designed? I say FIX >THE APPLICATION!
A good point. My impression is that there are two problems here: fork() and the use of sparse arrays. I believe few programs actually use sparse arrays, and those that do should be easily "fixable" with a slight performance hit. If you want to try.
You'll have a harder time with fork() though. A forking process may need to double its entire memory allocation, but it may also end up needing only a few pages.
Outlawing self-modifying code wil help to some extent. You won't need to reserve space for duplicating code. Data-intensive apps is a problem though.
fork() is a very useful call, but it makes good memory accounting hard. Guaranteeing all the memory is expensive, guaranteeing too little is risky, and auto-estimating is impossible.
You can create a /proc setting defining how many percent of allocations you need to guarantee. The paranoid may then use 100% and have lots of unused swap and few processes running. The daring can use 0% like today. Others may use some percentage based on actual-use measurements for typical uses (fileserver, webserver, login-server,...) Crashing these migth be *possible* using a designed attack, but normal use will fail on fork()/malloc() first. Administrators may then weigh cost (unused swap disks) against risk for each case. Implementing this is up to those who care.
An even better solution is to create alternatives to all memory-allocating calls (fork(), malloc()) that also specifies an estimate about how much of the memory we actually will use for that call. The os can then guarantee that amount. If OOM happens anyway - kill & log the process that went furtest above its own estimate. There will always be at least one. The downside is that you'll need to change all apps to take advantage of this, which will take some time. Again, implementing is up to those who care.
Helge Hafting
- 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/
|  |