lkml.org 
[lkml]   [2004]   [Jun]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 14:04    [W:0.126 / U:0.556 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site