[patch] make sysctl_overcommit_memory enumeration sensible

[patch] make sysctl_overcommit_memory enumeration sensible

[Coywolf Qi Hunt]

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 <qiyong@fc-cn.com>
---
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

Re: [patch] make sysctl_overcommit_memory enumeration sensible

[Nick Piggin]

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 <qiyong@fc-cn.com>
> ---
> 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 

Re: [patch] make sysctl_overcommit_memory enumeration sensible

[Andrew Morton]

Coywolf Qi Hunt <qiyong@fc-cn.com> 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.

Re: [patch] make sysctl_overcommit_memory enumeration sensible

[Coywolf Qi Hunt]

On Wed, Feb 15, 2006 at 01:05:59AM -0800, Andrew Morton wrote:
> Coywolf Qi Hunt <qiyong@fc-cn.com> 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

Re: [patch] make sysctl_overcommit_memory enumeration sensible

[Avi Kivity]

Coywolf Qi Hunt wrote:

>On Wed, Feb 15, 2006 at 01:05:59AM -0800, Andrew Morton wrote:
>  
>
>>Coywolf Qi Hunt <qiyong@fc-cn.com> 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

Re: [patch] make sysctl_overcommit_memory enumeration sensible

[Coywolf Qi Hunt]

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 <qiyong@fc-cn.com> 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

Re: [patch] make sysctl_overcommit_memory enumeration sensible

[Avi Kivity]

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

Re: [patch] make sysctl_overcommit_memory enumeration sensible

[Mark Hahn]

> 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.

Re: [patch] make sysctl_overcommit_memory enumeration sensible

[Coywolf Qi Hunt]

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 <qiyong@fc-cn.com>
> >---
> >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

Re: [patch] make sysctl_overcommit_memory enumeration sensible

[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

Re: [patch] make sysctl_overcommit_memory enumeration sensible

[Nick Piggin]

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