Re: Kernel VM bug?

[Hugh Dickins]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/