I see system admins often confused when they sysctl vm.overcommit_memory.
This patch makes overcommit_memory enumeration sensible.
0 - no overcommit
1 - always overcommit
2 - heuristic overcommit (default)
I don't feel this would break any userspace scripts. If it seems OK, I'll
update the documents.
Signed-off-by: Coywolf Qi Hunt <[email protected]>
---
diff --git a/include/linux/mman.h b/include/linux/mman.h
index 18a5689..e50f5ad 100644
--- a/include/linux/mman.h
+++ b/include/linux/mman.h
@@ -10,9 +10,9 @@
#define MREMAP_MAYMOVE 1
#define MREMAP_FIXED 2
-#define OVERCOMMIT_GUESS 0
+#define OVERCOMMIT_NEVER 0
#define OVERCOMMIT_ALWAYS 1
-#define OVERCOMMIT_NEVER 2
+#define OVERCOMMIT_GUESS 2
extern int sysctl_overcommit_memory;
extern int sysctl_overcommit_ratio;
extern atomic_t vm_committed_space;
--
Coywolf Qi Hunt
Coywolf Qi Hunt <[email protected]> wrote:
>
> I see system admins often confused when they sysctl vm.overcommit_memory.
> This patch makes overcommit_memory enumeration sensible.
>
> 0 - no overcommit
> 1 - always overcommit
> 2 - heuristic overcommit (default)
>
> I don't feel this would break any userspace scripts.
eh? If any such scripts exist, they'll break.
Confused.
On Wed, Feb 15, 2006 at 01:05:59AM -0800, Andrew Morton wrote:
> Coywolf Qi Hunt <[email protected]> wrote:
> >
> > I see system admins often confused when they sysctl vm.overcommit_memory.
> > This patch makes overcommit_memory enumeration sensible.
> >
> > 0 - no overcommit
> > 1 - always overcommit
> > 2 - heuristic overcommit (default)
> >
> > I don't feel this would break any userspace scripts.
>
> eh? If any such scripts exist, they'll break.
>
> Confused.
>
That's a corner case. Let'em break and fix. Otherwise, users will
be confused. Even they get it right, after some weeks they'll have
to re-read the doc. A logical user interface is important to human.
--
Coywolf Qi Hunt
Coywolf Qi Hunt wrote:
>On Wed, Feb 15, 2006 at 01:05:59AM -0800, Andrew Morton wrote:
>
>
>>Coywolf Qi Hunt <[email protected]> wrote:
>>
>>
>>>I see system admins often confused when they sysctl vm.overcommit_memory.
>>>This patch makes overcommit_memory enumeration sensible.
>>>
>>>0 - no overcommit
>>>1 - always overcommit
>>>2 - heuristic overcommit (default)
>>>
>>>I don't feel this would break any userspace scripts.
>>>
>>>
>>eh? If any such scripts exist, they'll break.
>>
>>Confused.
>>
>>
>
>That's a corner case. Let'em break and fix. Otherwise, users will
>be confused. Even they get it right, after some weeks they'll have
>to re-read the doc. A logical user interface is important to human.
>
>
If I have
vm.overcommit_memory = 2
in my /etc/sysctl.conf, its meaning silently changes. I'll know about it
during the next oomkiller pass.
--
error compiling committee.c: too many arguments to function
On Wed, Feb 15, 2006 at 12:32:38PM +0200, Avi Kivity wrote:
> Coywolf Qi Hunt wrote:
>
> >On Wed, Feb 15, 2006 at 01:05:59AM -0800, Andrew Morton wrote:
> >
> >
> >>Coywolf Qi Hunt <[email protected]> wrote:
> >>
> >>
> >>>I see system admins often confused when they sysctl
> >>>vm.overcommit_memory.
> >>>This patch makes overcommit_memory enumeration sensible.
> >>>
> >>>0 - no overcommit
> >>>1 - always overcommit
> >>>2 - heuristic overcommit (default)
> >>>
> >>>I don't feel this would break any userspace scripts.
> >>>
> >>>
> >>eh? If any such scripts exist, they'll break.
> >>
> >>Confused.
> >>
> >>
> >
> >That's a corner case. Let'em break and fix. Otherwise, users will
> >be confused. Even they get it right, after some weeks they'll have
> >to re-read the doc. A logical user interface is important to human.
> >
> >
>
> If I have
>
> vm.overcommit_memory = 2
>
> in my /etc/sysctl.conf, its meaning silently changes. I'll know about
> it during the next oomkiller pass.
Indeed. See, the breakage doesn't hurt.
--
Coywolf Qi Hunt
Coywolf Qi Hunt wrote:
> I see system admins often confused when they sysctl vm.overcommit_memory.
> This patch makes overcommit_memory enumeration sensible.
>
What's the point? The current has been there for a long time, and
is well documented.
> 0 - no overcommit
> 1 - always overcommit
> 2 - heuristic overcommit (default)
>
> I don't feel this would break any userspace scripts.
You mean, except for the ones that go `echo 0 > /proc/sys/vm/overcommit_memory`;
or `echo 2 > /proc/sys/vm/overcommit_memory` ?
And those sysctl configuration files that get set at bootup?
> If it seems OK, I'll
> update the documents.
>
> Signed-off-by: Coywolf Qi Hunt <[email protected]>
> ---
> diff --git a/include/linux/mman.h b/include/linux/mman.h
> index 18a5689..e50f5ad 100644
> --- a/include/linux/mman.h
> +++ b/include/linux/mman.h
> @@ -10,9 +10,9 @@
> #define MREMAP_MAYMOVE 1
> #define MREMAP_FIXED 2
>
> -#define OVERCOMMIT_GUESS 0
> +#define OVERCOMMIT_NEVER 0
> #define OVERCOMMIT_ALWAYS 1
> -#define OVERCOMMIT_NEVER 2
> +#define OVERCOMMIT_GUESS 2
> extern int sysctl_overcommit_memory;
> extern int sysctl_overcommit_ratio;
> extern atomic_t vm_committed_space;
>
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
Coywolf Qi Hunt wrote:
>>in my /etc/sysctl.conf, its meaning silently changes. I'll know about
>>it during the next oomkiller pass.
>>
>>
>
>Indeed. See, the breakage doesn't hurt.
>
>
I guess we have different definitions for 'hurt' in our dictionaries.
--
error compiling committee.c: too many arguments to function
> What's the point? The current has been there for a long time, and
> is well documented.
right - low-pointage user-space break. it _would_ make a small amount of
sense to use a string (never/guess/always works for me), but the existing
meanings (2/0/1 respectively) would need to be provided through a major
release cycle then generate an error if used...
regards, mark hahn.
On Wed, Feb 15, 2006 at 08:01:10PM +1100, Nick Piggin wrote:
> Coywolf Qi Hunt wrote:
> >I see system admins often confused when they sysctl vm.overcommit_memory.
> >This patch makes overcommit_memory enumeration sensible.
> >
>
> What's the point? The current has been there for a long time, and
> is well documented.
Yes, the current is well documented and for a long time. But the design is
insane, no matter how well and how long it is documented. Users have to read
the document for *many times*.
The new way is logical so it would let us "read once, remember always".
Coywolf
>
> >0 - no overcommit
> >1 - always overcommit
> >2 - heuristic overcommit (default)
> >
> >I don't feel this would break any userspace scripts.
>
> You mean, except for the ones that go `echo 0 >
> /proc/sys/vm/overcommit_memory`;
> or `echo 2 > /proc/sys/vm/overcommit_memory` ?
>
> And those sysctl configuration files that get set at bootup?
>
> >If it seems OK, I'll
> >update the documents.
> >
> >Signed-off-by: Coywolf Qi Hunt <[email protected]>
> >---
> >diff --git a/include/linux/mman.h b/include/linux/mman.h
> >index 18a5689..e50f5ad 100644
> >--- a/include/linux/mman.h
> >+++ b/include/linux/mman.h
> >@@ -10,9 +10,9 @@
> > #define MREMAP_MAYMOVE 1
> > #define MREMAP_FIXED 2
> >
> >-#define OVERCOMMIT_GUESS 0
> >+#define OVERCOMMIT_NEVER 0
> > #define OVERCOMMIT_ALWAYS 1
> >-#define OVERCOMMIT_NEVER 2
> >+#define OVERCOMMIT_GUESS 2
> > extern int sysctl_overcommit_memory;
> > extern int sysctl_overcommit_ratio;
> > extern atomic_t vm_committed_space;
> >
>
>
> --
> SUSE Labs, Novell Inc.
> Send instant messages to your online friends http://au.messenger.yahoo.com
>
--
Coywolf Qi Hunt
On Wed, Feb 15, 2006 at 03:04:31PM +0200, Avi Kivity wrote:
> Coywolf Qi Hunt wrote:
>
> >>in my /etc/sysctl.conf, its meaning silently changes. I'll know about
> >>it during the next oomkiller pass.
> >>
> >>
> >
> >Indeed. See, the breakage doesn't hurt.
Indeed. See, the breakage doesn't hurt (much).
> >
> >
> I guess we have different definitions for 'hurt' in our dictionaries.
>
> --
> error compiling committee.c: too many arguments to function
>
>
--
Coywolf Qi Hunt
Coywolf Qi Hunt wrote:
> On Wed, Feb 15, 2006 at 08:01:10PM +1100, Nick Piggin wrote:
>
>>Coywolf Qi Hunt wrote:
>>
>>>I see system admins often confused when they sysctl vm.overcommit_memory.
>>>This patch makes overcommit_memory enumeration sensible.
>>>
>>
>>What's the point? The current has been there for a long time, and
>>is well documented.
>
>
> Yes, the current is well documented and for a long time. But the design is
> insane, no matter how well and how long it is documented. Users have to read
> the document for *many times*.
>
> The new way is logical so it would let us "read once, remember always".
>
>
That's just not how it's done, full stop.
If it was really a big problem, you'd add a new sysctl with the new
behaviour, put a warning printk in the kernel that says the old one
is deprecated, wait for a year or so, then remove the old one.
But I suspect it simply doesn't matter that much in this case.
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com