Messages in this thread | | | Date | Mon, 28 Jun 2004 14:01:29 +0100 (BST) | From | Hugh Dickins <> | Subject | Re: Kernel VM bug? |
| |
On Sun, 27 Jun 2004, William Lee Irwin III wrote: > > Strict non-overcommit is also good to have in order for orderly > application shutdown or otherwise application self-regulation of > resource demands to occur at the time of hardware resource exhaustion. > This is by necessity enabled by default and has to be disabled at > runtime. You shouldn't have to do anything to enable it, but to > doublecheck that strict non-overcommit hasn't been disabled by e.g. > initscripts, please check that /proc/sys/vm/overcommit_memory stays 0.
I'm not sure if I'm niggling over terminology, or pointing out a significant misunderstanding: but /proc/sys/vm/overcommit_memory 0 (indeed the default) is not what I call strict non-overcommit: that's 2.
All settings (0, 1, 2) maintain the Committed_AS count shown in /proc/meminfo; but only /proc/sys/vm/overcommit_memory 2 totals and limits reservations using it. 1 imposes no limit. 0 checks that the particular "reservation" could plausibly be made available now, but without considering the total: so allows any number of concurrent maximum reservations - traditional relaxed Linux behaviour, not strict.
(2 came along much later, yes the naming and numbering are both horrid.)
Hugh
- 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/
| |