Messages in this thread | | | From | (david parsons) | Subject | Re: Overcommitable memory?? | Date | 23 Mar 2000 12:08:36 -0800 |
| |
In article <linux.kernel.slrn8dhb2e.ns.mnalis-news@eagle.home.lan>, Matija Nalis <mnalis@jagor.srce.hr> wrote:
>Yes, but it impose too much overhead. >It means no COW (or preallocate on COW) >It means no growable stack (so, what, you just allocate maximum amount ? 8 >MB ? 32 MB ? 256 MB ? 1 G? PER PROCESS!)
No it doesn't.
What it does mean that if a process writes a COW page and there's no space for the page, that process dies. It does mean that if a process attempted to grow its stack and there's no space, that process dies.
The computational overhead for non-overcommit is less than the overhead for overcommit + some all-singing all-dancing oom killer that has to make decisions about which process to kill.
>Imagine: >100 apache servers running >inetd >syslog > >www connections are coming happily, and then one FTP connection comes. inetd >spawns ftpd, and few more apaches fork(). ftpd tries to log connection to >syslog, and syslog fails to malloc().
Sysklogd, if it can't malloc() for a message fragment, simply logs that it can't get memory and continues.
>System is non-overcommiting. You have OOM. Only question is who do you kill >(and it is the same question as with overcommiting system!!):
No, there is no need to kill anything here.
> (in the meantime, TCP connections continue coming in, >and now kernels wants to allocate some more networking buffers, but is OOM)
So it drops the traffic on the floor (while complaining bitterly about the lack of memory, which is -- unless my syslog is lying to me -- what it does right now)
____ david parsons \bi/ I'd rather have to have 128mb of vm because I needed \/ it than have 128mb of vm because I need a large buffer against overcommit.
- 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/
| |