Messages in this thread | | | From | "David Luyer" <> | Subject | RE: vm philosophising | Date | Sat, 19 Jan 2002 15:42:45 +1100 |
| |
Alan Cox wrote: > > There is another VM that has a property that people would like: > > deterministically handling memory exhaustion. Unfortunately, that VM > > probably can't co-exist with over-commit and the > performance gains that > > affords. > > It can definitely co-exist. Overcommit control is just a book keeping > exercise on address space commits.
And that's a _definitely_; other OS's have done it. Digital Unix, for one, on the basis of a file called 'swapdefault', swapped between overcommit and precommit modes. I was rather disappointed when I first tried to enable overcommit mode on Solaris 2.x (where 'x' was probably somewhere around 4) and searched for quite some time before giving up and deciding it wasn't a tunable option...
Although I've never actually deliberately run a system in precommit mode, it always used to be the first thing to "fix" on a Digital Unix box, and when I discovered Solaris had the same "flaw" my suggestion was to move the affected applications (large applications which fork before exec'ing or fork short lived-children, at around 1/2Gb+ each, which should just be short-lived COW shared mappings and not exhaust memory) to Linux.
And while precommit may be something people ask for, I'd have to say many of them would, having experienced the difference on identical hardware, then realise what a bad idea it was and go back to the current mode. That is, it sounds like a big waste of time to implement the 'traditional' behaviour which Linux is already so much better than.
David. -- David Luyer Phone: +61 3 9674 7525 Network Manager P A C I F I C Fax: +61 3 9699 8693 Pacific Internet (Australia) I N T E R N E T Mobile: +61 4 1111 BYTE http://www.pacific.net.au/ NASDAQ: PCNTF
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |