>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/
This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:19 EST