[PATCH v2 1/4] mm: completely disable THP by transparent_hugepage=0

[PATCH v2 1/4] mm: completely disable THP by transparent_hugepage=0

[Amerigo Wang]

Introduce "transparent_hugepage=0" to totally disable THP.
"transparent_hugepage=never" means setting THP to be partially
disabled, we need a new way to totally disable it.

Signed-off-by: WANG Cong <amwang@redhat.com>
---
 Documentation/vm/transhuge.txt |    3 ++-
 mm/huge_memory.c               |   12 ++++++++++++
 2 files changed, 14 insertions(+), 1 deletions(-)

diff --git a/Documentation/vm/transhuge.txt b/Documentation/vm/transhuge.txt
index 0924aac..43c4d53 100644
--- a/Documentation/vm/transhuge.txt
+++ b/Documentation/vm/transhuge.txt
@@ -156,7 +156,8 @@ for each pass:
 You can change the sysfs boot time defaults of Transparent Hugepage
 Support by passing the parameter "transparent_hugepage=always" or
 "transparent_hugepage=madvise" or "transparent_hugepage=never"
-(without "") to the kernel command line.
+(without "") to the kernel command line. To totally disable this
+feature, pass "transparent_hugepage=0".
 
 == Need of application restart ==
 
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 81532f2..e4a4f2b 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -488,6 +488,8 @@ static struct attribute_group khugepaged_attr_group = {
 };
 #endif /* CONFIG_SYSFS */
 
+static int no_hugepage_init;
+
 static int __init hugepage_init(void)
 {
 	int err;
@@ -501,6 +503,13 @@ static int __init hugepage_init(void)
 		goto out;
 	}
 
+	if (no_hugepage_init) {
+		err = 0;
+		transparent_hugepage_flags = 0;
+		printk(KERN_INFO "hugepage: totally disabled\n");
+		goto out;
+	}
+
 #ifdef CONFIG_SYSFS
 	err = -ENOMEM;
 	hugepage_kobj = kobject_create_and_add("transparent_hugepage", mm_kobj);
@@ -572,6 +581,9 @@ static int __init setup_transparent_hugepage(char *str)
 		clear_bit(TRANSPARENT_HUGEPAGE_REQ_MADV_FLAG,
 			  &transparent_hugepage_flags);
 		ret = 1;
+	} else if (!strcmp(str, "0")) {
+		no_hugepage_init = 1;
+		ret = 1;
 	}
 out:
 	if (!ret)
-- 
1.7.4.4

[PATCH v2 1/4] mm: completely disable THP by transparent_hugepage=0

[Amerigo Wang]

Introduce "transparent_hugepage=0" to totally disable THP.
"transparent_hugepage=never" means setting THP to be partially
disabled, we need a new way to totally disable it.

Signed-off-by: WANG Cong <amwang@redhat.com>
---
 Documentation/vm/transhuge.txt |    3 ++-
 mm/huge_memory.c               |   12 ++++++++++++
 2 files changed, 14 insertions(+), 1 deletions(-)

diff --git a/Documentation/vm/transhuge.txt b/Documentation/vm/transhuge.txt
index 0924aac..43c4d53 100644
--- a/Documentation/vm/transhuge.txt
+++ b/Documentation/vm/transhuge.txt
@@ -156,7 +156,8 @@ for each pass:
 You can change the sysfs boot time defaults of Transparent Hugepage
 Support by passing the parameter "transparent_hugepage=always" or
 "transparent_hugepage=madvise" or "transparent_hugepage=never"
-(without "") to the kernel command line.
+(without "") to the kernel command line. To totally disable this
+feature, pass "transparent_hugepage=0".
 
 == Need of application restart ==
 
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 81532f2..e4a4f2b 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -488,6 +488,8 @@ static struct attribute_group khugepaged_attr_group = {
 };
 #endif /* CONFIG_SYSFS */
 
+static int no_hugepage_init;
+
 static int __init hugepage_init(void)
 {
 	int err;
@@ -501,6 +503,13 @@ static int __init hugepage_init(void)
 		goto out;
 	}
 
+	if (no_hugepage_init) {
+		err = 0;
+		transparent_hugepage_flags = 0;
+		printk(KERN_INFO "hugepage: totally disabled\n");
+		goto out;
+	}
+
 #ifdef CONFIG_SYSFS
 	err = -ENOMEM;
 	hugepage_kobj = kobject_create_and_add("transparent_hugepage", mm_kobj);
@@ -572,6 +581,9 @@ static int __init setup_transparent_hugepage(char *str)
 		clear_bit(TRANSPARENT_HUGEPAGE_REQ_MADV_FLAG,
 			  &transparent_hugepage_flags);
 		ret = 1;
+	} else if (!strcmp(str, "0")) {
+		no_hugepage_init = 1;
+		ret = 1;
 	}
 out:
 	if (!ret)
-- 
1.7.4.4

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH v2 2/4] mm: make the threshold of enabling THP configurable

[Amerigo Wang]

Don't hard-code 512M as the threshold in kernel, make it configruable,
and set 512M by default.

And print info when THP is disabled automatically on small systems.

V2: Add more description in help messages, correct some typos,
print the mini threshold too.

Cc: dave@linux.vnet.ibm.com
Signed-off-by: WANG Cong <amwang@redhat.com>
---
 mm/Kconfig       |   20 ++++++++++++++++++++
 mm/huge_memory.c |    7 ++++++-
 2 files changed, 26 insertions(+), 1 deletions(-)

diff --git a/mm/Kconfig b/mm/Kconfig
index 8ca47a5..f1b3175f 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -340,6 +340,26 @@ choice
 	  benefit.
 endchoice
 
+config TRANSPARENT_HUGEPAGE_THRESHOLD
+	depends on TRANSPARENT_HUGEPAGE
+	int "The minimal threshold of enabling Transparent Hugepage"
+	range 512 8192
+	default "512"
+	help
+	  The threshold of enabling Transparent Huagepage automatically,
+	  in Mbytes, below this value Transparent Hugepage will be disabled
+	  by default during boot. You can still enable it via /sys after
+	  boot.
+
+	  Transparent hugepages are created by moving other pages out of
+	  the way to create large, contiguous swaths of free memory.
+	  However, some memory on a system can not be easily moved.  It is
+	  likely on small systems that this unmovable memory will occupy a
+	  large portion of total memory, which makes even attempting to
+	  create transparent hugepages very expensive.
+
+	  If you are unsure, set this to the smallest possible value.
+
 #
 # UP and nommu archs use km based percpu allocator
 #
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index e4a4f2b..126c96b 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -546,8 +546,13 @@ static int __init hugepage_init(void)
 	 * where the extra memory used could hurt more than TLB overhead
 	 * is likely to save.  The admin can still enable it through /sys.
 	 */
-	if (totalram_pages < (512 << (20 - PAGE_SHIFT)))
+	if (totalram_pages < (CONFIG_TRANSPARENT_HUGEPAGE_THRESHOLD
+					<< (20 - PAGE_SHIFT))) {
+		printk(KERN_INFO "THP: disabled automatically"
+				 "with less than %dMB of RAM\n",
+				 CONFIG_TRANSPARENT_HUGEPAGE_THRESHOLD);
 		transparent_hugepage_flags = 0;
+	}
 
 	start_khugepaged();
 
-- 
1.7.4.4

[PATCH v2 2/4] mm: make the threshold of enabling THP configurable

[Amerigo Wang]

Don't hard-code 512M as the threshold in kernel, make it configruable,
and set 512M by default.

And print info when THP is disabled automatically on small systems.

V2: Add more description in help messages, correct some typos,
print the mini threshold too.

Cc: dave@linux.vnet.ibm.com
Signed-off-by: WANG Cong <amwang@redhat.com>
---
 mm/Kconfig       |   20 ++++++++++++++++++++
 mm/huge_memory.c |    7 ++++++-
 2 files changed, 26 insertions(+), 1 deletions(-)

diff --git a/mm/Kconfig b/mm/Kconfig
index 8ca47a5..f1b3175f 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -340,6 +340,26 @@ choice
 	  benefit.
 endchoice
 
+config TRANSPARENT_HUGEPAGE_THRESHOLD
+	depends on TRANSPARENT_HUGEPAGE
+	int "The minimal threshold of enabling Transparent Hugepage"
+	range 512 8192
+	default "512"
+	help
+	  The threshold of enabling Transparent Huagepage automatically,
+	  in Mbytes, below this value Transparent Hugepage will be disabled
+	  by default during boot. You can still enable it via /sys after
+	  boot.
+
+	  Transparent hugepages are created by moving other pages out of
+	  the way to create large, contiguous swaths of free memory.
+	  However, some memory on a system can not be easily moved.  It is
+	  likely on small systems that this unmovable memory will occupy a
+	  large portion of total memory, which makes even attempting to
+	  create transparent hugepages very expensive.
+
+	  If you are unsure, set this to the smallest possible value.
+
 #
 # UP and nommu archs use km based percpu allocator
 #
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index e4a4f2b..126c96b 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -546,8 +546,13 @@ static int __init hugepage_init(void)
 	 * where the extra memory used could hurt more than TLB overhead
 	 * is likely to save.  The admin can still enable it through /sys.
 	 */
-	if (totalram_pages < (512 << (20 - PAGE_SHIFT)))
+	if (totalram_pages < (CONFIG_TRANSPARENT_HUGEPAGE_THRESHOLD
+					<< (20 - PAGE_SHIFT))) {
+		printk(KERN_INFO "THP: disabled automatically"
+				 "with less than %dMB of RAM\n",
+				 CONFIG_TRANSPARENT_HUGEPAGE_THRESHOLD);
 		transparent_hugepage_flags = 0;
+	}
 
 	start_khugepaged();
 
-- 
1.7.4.4

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 2/4] mm: make the threshold of enabling THP configurable

[Dave Hansen]

On Tue, 2011-06-21 at 16:10 +0800, Amerigo Wang wrote:
> Don't hard-code 512M as the threshold in kernel, make it configruable,
> and set 512M by default.
> 
> And print info when THP is disabled automatically on small systems.
> 
> V2: Add more description in help messages, correct some typos,
> print the mini threshold too.

This seems sane to me.  The printk probably could probably stand by
itself, btw.  But, this is a small enough patch that it's fine.

Signed-off-by: Dave Hansen <dave@linux.vnet.ibm.com>

Re: [PATCH v2 2/4] mm: make the threshold of enabling THP configurable

[Dave Hansen]

On Tue, 2011-06-21 at 16:10 +0800, Amerigo Wang wrote:
> Don't hard-code 512M as the threshold in kernel, make it configruable,
> and set 512M by default.
> 
> And print info when THP is disabled automatically on small systems.
> 
> V2: Add more description in help messages, correct some typos,
> print the mini threshold too.

This seems sane to me.  The printk probably could probably stand by
itself, btw.  But, this is a small enough patch that it's fine.

Signed-off-by: Dave Hansen <dave@linux.vnet.ibm.com>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 2/4] mm: make the threshold of enabling THP configurable

[Dave Hansen]

Urg.  Pasted the wrong thing.  Should be:

Acked-by: Dave Hansen <dave@linux.vnet.ibm.com> 

-- Dave

Re: [PATCH v2 2/4] mm: make the threshold of enabling THP configurable

[Dave Hansen]

Urg.  Pasted the wrong thing.  Should be:

Acked-by: Dave Hansen <dave@linux.vnet.ibm.com> 

-- Dave

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 2/4] mm: make the threshold of enabling THP configurable

[David Rientjes]

On Tue, 21 Jun 2011, Amerigo Wang wrote:

> Don't hard-code 512M as the threshold in kernel, make it configruable,
> and set 512M by default.
> 
> And print info when THP is disabled automatically on small systems.
> 
> V2: Add more description in help messages, correct some typos,
> print the mini threshold too.
> 

I like the printk that notifies users why THP was disabled because it 
could potentially be a source of confusion (and fixing the existing typos 
in hugepage_init() would also be good).  However, I disagree that we need 
to have this as a config option: you either want the feature for your 
systems or you don't.  Perhaps add a "transparent_hugepage=force" option 
that will act as "always" but also force it to be enabled in all 
scenarios, even without X86_FEATURE_PSE, that will override all the logic 
that thinks it knows better?

Re: [PATCH v2 2/4] mm: make the threshold of enabling THP configurable

[David Rientjes]

On Tue, 21 Jun 2011, Amerigo Wang wrote:

> Don't hard-code 512M as the threshold in kernel, make it configruable,
> and set 512M by default.
> 
> And print info when THP is disabled automatically on small systems.
> 
> V2: Add more description in help messages, correct some typos,
> print the mini threshold too.
> 

I like the printk that notifies users why THP was disabled because it 
could potentially be a source of confusion (and fixing the existing typos 
in hugepage_init() would also be good).  However, I disagree that we need 
to have this as a config option: you either want the feature for your 
systems or you don't.  Perhaps add a "transparent_hugepage=force" option 
that will act as "always" but also force it to be enabled in all 
scenarios, even without X86_FEATURE_PSE, that will override all the logic 
that thinks it knows better?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 2/4] mm: make the threshold of enabling THP configurable

[Cong Wang]

于 2011年06月22日 09:23, David Rientjes 写道:
> On Tue, 21 Jun 2011, Amerigo Wang wrote:
>
>> Don't hard-code 512M as the threshold in kernel, make it configruable,
>> and set 512M by default.
>>
>> And print info when THP is disabled automatically on small systems.
>>
>> V2: Add more description in help messages, correct some typos,
>> print the mini threshold too.
>>
>
> I like the printk that notifies users why THP was disabled because it
> could potentially be a source of confusion (and fixing the existing typos
> in hugepage_init() would also be good).  However, I disagree that we need
> to have this as a config option: you either want the feature for your
> systems or you don't.  Perhaps add a "transparent_hugepage=force" option
> that will act as "always" but also force it to be enabled in all
> scenarios, even without X86_FEATURE_PSE, that will override all the logic
> that thinks it knows better?

I think that is overkill, because we can still enable THP via /sys
for small systems.

Thanks.

Re: [PATCH v2 2/4] mm: make the threshold of enabling THP configurable

[Cong Wang]

ao? 2011a1'06ae??22ae?JPY 09:23, David Rientjes a??e??:
> On Tue, 21 Jun 2011, Amerigo Wang wrote:
>
>> Don't hard-code 512M as the threshold in kernel, make it configruable,
>> and set 512M by default.
>>
>> And print info when THP is disabled automatically on small systems.
>>
>> V2: Add more description in help messages, correct some typos,
>> print the mini threshold too.
>>
>
> I like the printk that notifies users why THP was disabled because it
> could potentially be a source of confusion (and fixing the existing typos
> in hugepage_init() would also be good).  However, I disagree that we need
> to have this as a config option: you either want the feature for your
> systems or you don't.  Perhaps add a "transparent_hugepage=force" option
> that will act as "always" but also force it to be enabled in all
> scenarios, even without X86_FEATURE_PSE, that will override all the logic
> that thinks it knows better?

I think that is overkill, because we can still enable THP via /sys
for small systems.

Thanks.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 2/4] mm: make the threshold of enabling THP configurable

[David Rientjes]

On Wed, 22 Jun 2011, Cong Wang wrote:

> > I like the printk that notifies users why THP was disabled because it
> > could potentially be a source of confusion (and fixing the existing typos
> > in hugepage_init() would also be good).  However, I disagree that we need
> > to have this as a config option: you either want the feature for your
> > systems or you don't.  Perhaps add a "transparent_hugepage=force" option
> > that will act as "always" but also force it to be enabled in all
> > scenarios, even without X86_FEATURE_PSE, that will override all the logic
> > that thinks it knows better?
> 
> I think that is overkill, because we can still enable THP via /sys
> for small systems.
> 

That was already possible before your patch, your patch is only 
introducing a configuration value that determines whether it is enabled by 
default or not.  I was proposing a very simple interface that would 
override all logic that could be used instead when you know for certain 
that you want THP enabled by default regardless of its logic.  That's 
extendable because it can bypass any additional code added later to 
determine when it should default on or off without adding additional 
config options.  I wouldn't support an additional command line option, but 
rather only an additional option for transparent_hugepage=.

Either way, this patch isn't needed since it has no benefit over doing it 
through an init script.

Re: [PATCH v2 2/4] mm: make the threshold of enabling THP configurable

[David Rientjes]

On Wed, 22 Jun 2011, Cong Wang wrote:

> > I like the printk that notifies users why THP was disabled because it
> > could potentially be a source of confusion (and fixing the existing typos
> > in hugepage_init() would also be good).  However, I disagree that we need
> > to have this as a config option: you either want the feature for your
> > systems or you don't.  Perhaps add a "transparent_hugepage=force" option
> > that will act as "always" but also force it to be enabled in all
> > scenarios, even without X86_FEATURE_PSE, that will override all the logic
> > that thinks it knows better?
> 
> I think that is overkill, because we can still enable THP via /sys
> for small systems.
> 

That was already possible before your patch, your patch is only 
introducing a configuration value that determines whether it is enabled by 
default or not.  I was proposing a very simple interface that would 
override all logic that could be used instead when you know for certain 
that you want THP enabled by default regardless of its logic.  That's 
extendable because it can bypass any additional code added later to 
determine when it should default on or off without adding additional 
config options.  I wouldn't support an additional command line option, but 
rather only an additional option for transparent_hugepage=.

Either way, this patch isn't needed since it has no benefit over doing it 
through an init script.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 2/4] mm: make the threshold of enabling THP configurable

[Cong Wang]

于 2011年06月22日 11:29, David Rientjes 写道:
>
> Either way, this patch isn't needed since it has no benefit over doing it
> through an init script.

If you were right, CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS is not needed,
you can do it through an init script.

If you were right, the 512M limit is not needed neither, you have
transparent_hugepage=never boot parameter and do the check of
512M later in an init script. (Actually, moving the 512M check to
user-space is really more sane to me.)

I am quite sure you have lots of other things which both have a Kconfig
and a boot parameter, why do we have it?

Re: [PATCH v2 2/4] mm: make the threshold of enabling THP configurable

[Cong Wang]

ao? 2011a1'06ae??22ae?JPY 11:29, David Rientjes a??e??:
>
> Either way, this patch isn't needed since it has no benefit over doing it
> through an init script.

If you were right, CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS is not needed,
you can do it through an init script.

If you were right, the 512M limit is not needed neither, you have
transparent_hugepage=never boot parameter and do the check of
512M later in an init script. (Actually, moving the 512M check to
user-space is really more sane to me.)

I am quite sure you have lots of other things which both have a Kconfig
and a boot parameter, why do we have it?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 2/4] mm: make the threshold of enabling THP configurable

[David Rientjes]

On Wed, 22 Jun 2011, Cong Wang wrote:

> > Either way, this patch isn't needed since it has no benefit over doing it
> > through an init script.
> 
> If you were right, CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS is not needed,
> you can do it through an init script.
> 

They are really two different things: config options like 
CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS and CONFIG_SLUB_DEBUG_ON are shortcuts 
for command line options when you want the _default_ behavior to be 
specified.  They could easily be done on the command line just as they can 
be done in the config.  They typically have far reaching consequences 
depending on whether they are enabled or disabled and warrant the entry in 
the config file.

This patch, however, is not making the heuristic any easier to work with; 
in fact, if the default were ever changed or the value is changed on your 
kernel, then certain kernels will have THP enabled by default and others 
will not.  That's why I suggested an override command line option like 
transparent_hugepage=force to ignore any disabling heursitics either 
present or future.

> If you were right, the 512M limit is not needed neither, you have
> transparent_hugepage=never boot parameter and do the check of
> 512M later in an init script. (Actually, moving the 512M check to
> user-space is really more sane to me.)
> 

It's quite obvious that the default behavior intended by the author is 
that it is defaulted off for systems with less than 512M of memory.  
Obfuscating that probably isn't a very good idea, but I'm always in favor 
of command lines that allow users to override settings when they really do 
know better.

Re: [PATCH v2 2/4] mm: make the threshold of enabling THP configurable

[David Rientjes]

On Wed, 22 Jun 2011, Cong Wang wrote:

> > Either way, this patch isn't needed since it has no benefit over doing it
> > through an init script.
> 
> If you were right, CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS is not needed,
> you can do it through an init script.
> 

They are really two different things: config options like 
CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS and CONFIG_SLUB_DEBUG_ON are shortcuts 
for command line options when you want the _default_ behavior to be 
specified.  They could easily be done on the command line just as they can 
be done in the config.  They typically have far reaching consequences 
depending on whether they are enabled or disabled and warrant the entry in 
the config file.

This patch, however, is not making the heuristic any easier to work with; 
in fact, if the default were ever changed or the value is changed on your 
kernel, then certain kernels will have THP enabled by default and others 
will not.  That's why I suggested an override command line option like 
transparent_hugepage=force to ignore any disabling heursitics either 
present or future.

> If you were right, the 512M limit is not needed neither, you have
> transparent_hugepage=never boot parameter and do the check of
> 512M later in an init script. (Actually, moving the 512M check to
> user-space is really more sane to me.)
> 

It's quite obvious that the default behavior intended by the author is 
that it is defaulted off for systems with less than 512M of memory.  
Obfuscating that probably isn't a very good idea, but I'm always in favor 
of command lines that allow users to override settings when they really do 
know better.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 2/4] mm: make the threshold of enabling THP configurable

[Cong Wang]

于 2011年06月22日 14:32, David Rientjes 写道:
> On Wed, 22 Jun 2011, Cong Wang wrote:
>
>>> Either way, this patch isn't needed since it has no benefit over doing it
>>> through an init script.
>>
>> If you were right, CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS is not needed,
>> you can do it through an init script.
>>
>
> They are really two different things: config options like
> CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS and CONFIG_SLUB_DEBUG_ON are shortcuts
> for command line options when you want the _default_ behavior to be
> specified.  They could easily be done on the command line just as they can
> be done in the config.  They typically have far reaching consequences
> depending on whether they are enabled or disabled and warrant the entry in
> the config file.
>
> This patch, however, is not making the heuristic any easier to work with;
> in fact, if the default were ever changed or the value is changed on your
> kernel, then certain kernels will have THP enabled by default and others
> will not.  That's why I suggested an override command line option like
> transparent_hugepage=force to ignore any disabling heursitics either
> present or future.

Actually, if we move this out of kernel, to user-space, everything
you worried will be solved by just changing the user-space code.
Just add the following pseudo code into your init script,

if [ $total_memory -lt 512 ]
then
	echo never > /sys/kernel/mm/transparent_hugepage/enabled
fi

BTW, "=force" makes people confused with "=always", like "=never"
actually means "=disabled".

>
>> If you were right, the 512M limit is not needed neither, you have
>> transparent_hugepage=never boot parameter and do the check of
>> 512M later in an init script. (Actually, moving the 512M check to
>> user-space is really more sane to me.)
>>
>
> It's quite obvious that the default behavior intended by the author is
> that it is defaulted off for systems with less than 512M of memory.
> Obfuscating that probably isn't a very good idea, but I'm always in favor
> of command lines that allow users to override settings when they really do
> know better.

The better way to express this is to add one line in Kconfig help said
"Please set CONFIG_THP_NEVER=y when you have less than 512M memory",
rather than enforcing a decision in code.

 From either aspect, I don't think the current 512M check code in kernel
is a good thing.

Thanks.

Re: [PATCH v2 2/4] mm: make the threshold of enabling THP configurable

[Cong Wang]

ao? 2011a1'06ae??22ae?JPY 14:32, David Rientjes a??e??:
> On Wed, 22 Jun 2011, Cong Wang wrote:
>
>>> Either way, this patch isn't needed since it has no benefit over doing it
>>> through an init script.
>>
>> If you were right, CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS is not needed,
>> you can do it through an init script.
>>
>
> They are really two different things: config options like
> CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS and CONFIG_SLUB_DEBUG_ON are shortcuts
> for command line options when you want the _default_ behavior to be
> specified.  They could easily be done on the command line just as they can
> be done in the config.  They typically have far reaching consequences
> depending on whether they are enabled or disabled and warrant the entry in
> the config file.
>
> This patch, however, is not making the heuristic any easier to work with;
> in fact, if the default were ever changed or the value is changed on your
> kernel, then certain kernels will have THP enabled by default and others
> will not.  That's why I suggested an override command line option like
> transparent_hugepage=force to ignore any disabling heursitics either
> present or future.

Actually, if we move this out of kernel, to user-space, everything
you worried will be solved by just changing the user-space code.
Just add the following pseudo code into your init script,

if [ $total_memory -lt 512 ]
then
	echo never > /sys/kernel/mm/transparent_hugepage/enabled
fi

BTW, "=force" makes people confused with "=always", like "=never"
actually means "=disabled".

>
>> If you were right, the 512M limit is not needed neither, you have
>> transparent_hugepage=never boot parameter and do the check of
>> 512M later in an init script. (Actually, moving the 512M check to
>> user-space is really more sane to me.)
>>
>
> It's quite obvious that the default behavior intended by the author is
> that it is defaulted off for systems with less than 512M of memory.
> Obfuscating that probably isn't a very good idea, but I'm always in favor
> of command lines that allow users to override settings when they really do
> know better.

The better way to express this is to add one line in Kconfig help said
"Please set CONFIG_THP_NEVER=y when you have less than 512M memory",
rather than enforcing a decision in code.

 From either aspect, I don't think the current 512M check code in kernel
is a good thing.

Thanks.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 2/4] mm: make the threshold of enabling THP configurable

[Andrea Arcangeli]

On Wed, Jun 22, 2011 at 07:07:25PM +0800, Cong Wang wrote:
> Actually, if we move this out of kernel, to user-space, everything
> you worried will be solved by just changing the user-space code.
> Just add the following pseudo code into your init script,
> 
> if [ $total_memory -lt 512 ]
> then
> 	echo never > /sys/kernel/mm/transparent_hugepage/enabled
> fi

By the time this script runs some app may have allocated hugepages
already potentially wasting mbytes of ram and undoing the
min_free_kbytes isn't possible from userland using the kernel
algorithm (it is possible actually but it's not nearly as simple as
the above).

There's no reason to complicate things and involve userland here when
a simple kernel check can get the default right without userland
dependency. Plus if this user really wants THP on 512m of ram he can
still enable it and run hugeadm to enable antifrag too, without the
need of =force. And forcing when PSE is enabled sounds impossible to be
useful (maybe with the except of nopentium being passed to the kernel ;).

There is no bug here, just send that printk cleanup and if you really
want to save 8k the patch to change the number of hash heads structs
at boot, like for dcache/icache. No other change required.

After you do the above, you can go ahead picking one kernel crashing
bug and fix it, that is more useful than making this 512m thing a
.config variable or anything like that, .config is a nightmare already
so it's probably better not to add anything there.

Re: [PATCH v2 2/4] mm: make the threshold of enabling THP configurable

[Andrea Arcangeli]

On Wed, Jun 22, 2011 at 07:07:25PM +0800, Cong Wang wrote:
> Actually, if we move this out of kernel, to user-space, everything
> you worried will be solved by just changing the user-space code.
> Just add the following pseudo code into your init script,
> 
> if [ $total_memory -lt 512 ]
> then
> 	echo never > /sys/kernel/mm/transparent_hugepage/enabled
> fi

By the time this script runs some app may have allocated hugepages
already potentially wasting mbytes of ram and undoing the
min_free_kbytes isn't possible from userland using the kernel
algorithm (it is possible actually but it's not nearly as simple as
the above).

There's no reason to complicate things and involve userland here when
a simple kernel check can get the default right without userland
dependency. Plus if this user really wants THP on 512m of ram he can
still enable it and run hugeadm to enable antifrag too, without the
need of =force. And forcing when PSE is enabled sounds impossible to be
useful (maybe with the except of nopentium being passed to the kernel ;).

There is no bug here, just send that printk cleanup and if you really
want to save 8k the patch to change the number of hash heads structs
at boot, like for dcache/icache. No other change required.

After you do the above, you can go ahead picking one kernel crashing
bug and fix it, that is more useful than making this 512m thing a
.config variable or anything like that, .config is a nightmare already
so it's probably better not to add anything there.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 2/4] mm: make the threshold of enabling THP configurable

[Cong Wang]

于 2011年06月22日 22:40, Andrea Arcangeli 写道:
> On Wed, Jun 22, 2011 at 07:07:25PM +0800, Cong Wang wrote:
>> Actually, if we move this out of kernel, to user-space, everything
>> you worried will be solved by just changing the user-space code.
>> Just add the following pseudo code into your init script,
>>
>> if [ $total_memory -lt 512 ]
>> then
>> 	echo never>  /sys/kernel/mm/transparent_hugepage/enabled
>> fi
>
> By the time this script runs some app may have allocated hugepages
> already potentially wasting mbytes of ram and undoing the
> min_free_kbytes isn't possible from userland using the kernel
> algorithm (it is possible actually but it's not nearly as simple as
> the above).

I remember there is a way to tell init-scripts to run it as early as
possible. :)

>
> There's no reason to complicate things and involve userland here when
> a simple kernel check can get the default right without userland
> dependency. Plus if this user really wants THP on 512m of ram he can
> still enable it and run hugeadm to enable antifrag too, without the
> need of =force. And forcing when PSE is enabled sounds impossible to be
> useful (maybe with the except of nopentium being passed to the kernel ;).
>
> There is no bug here, just send that printk cleanup and if you really
> want to save 8k the patch to change the number of hash heads structs
> at boot, like for dcache/icache. No other change required.


I never said this is a bug, I just don't think it is flexible. ;)

>
> After you do the above, you can go ahead picking one kernel crashing
> bug and fix it, that is more useful than making this 512m thing a
> .config variable or anything like that, .config is a nightmare already
> so it's probably better not to add anything there.

Well, I can't agree with this point.

Since we can't persuade each other, I give up.

Thanks.

Re: [PATCH v2 2/4] mm: make the threshold of enabling THP configurable

[Cong Wang]

ao? 2011a1'06ae??22ae?JPY 22:40, Andrea Arcangeli a??e??:
> On Wed, Jun 22, 2011 at 07:07:25PM +0800, Cong Wang wrote:
>> Actually, if we move this out of kernel, to user-space, everything
>> you worried will be solved by just changing the user-space code.
>> Just add the following pseudo code into your init script,
>>
>> if [ $total_memory -lt 512 ]
>> then
>> 	echo never>  /sys/kernel/mm/transparent_hugepage/enabled
>> fi
>
> By the time this script runs some app may have allocated hugepages
> already potentially wasting mbytes of ram and undoing the
> min_free_kbytes isn't possible from userland using the kernel
> algorithm (it is possible actually but it's not nearly as simple as
> the above).

I remember there is a way to tell init-scripts to run it as early as
possible. :)

>
> There's no reason to complicate things and involve userland here when
> a simple kernel check can get the default right without userland
> dependency. Plus if this user really wants THP on 512m of ram he can
> still enable it and run hugeadm to enable antifrag too, without the
> need of =force. And forcing when PSE is enabled sounds impossible to be
> useful (maybe with the except of nopentium being passed to the kernel ;).
>
> There is no bug here, just send that printk cleanup and if you really
> want to save 8k the patch to change the number of hash heads structs
> at boot, like for dcache/icache. No other change required.


I never said this is a bug, I just don't think it is flexible. ;)

>
> After you do the above, you can go ahead picking one kernel crashing
> bug and fix it, that is more useful than making this 512m thing a
> .config variable or anything like that, .config is a nightmare already
> so it's probably better not to add anything there.

Well, I can't agree with this point.

Since we can't persuade each other, I give up.

Thanks.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH 3/4] mm: improve THP printk messages

[Amerigo Wang]

As Andrea suggested, use "THP:" prefix to avoid
being confused with hugetlb.

Signed-off-by: WANG Cong <amwang@redhat.com>
---
 mm/huge_memory.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 126c96b..f9e720c 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -506,7 +506,7 @@ static int __init hugepage_init(void)
 	if (no_hugepage_init) {
 		err = 0;
 		transparent_hugepage_flags = 0;
-		printk(KERN_INFO "hugepage: totally disabled\n");
+		printk(KERN_INFO "THP: totally disabled\n");
 		goto out;
 	}
 
@@ -514,19 +514,19 @@ static int __init hugepage_init(void)
 	err = -ENOMEM;
 	hugepage_kobj = kobject_create_and_add("transparent_hugepage", mm_kobj);
 	if (unlikely(!hugepage_kobj)) {
-		printk(KERN_ERR "hugepage: failed kobject create\n");
+		printk(KERN_ERR "THP: failed kobject create\n");
 		goto out;
 	}
 
 	err = sysfs_create_group(hugepage_kobj, &hugepage_attr_group);
 	if (err) {
-		printk(KERN_ERR "hugepage: failed register hugeage group\n");
+		printk(KERN_ERR "THP: failed register hugeage group\n");
 		goto out;
 	}
 
 	err = sysfs_create_group(hugepage_kobj, &khugepaged_attr_group);
 	if (err) {
-		printk(KERN_ERR "hugepage: failed register hugeage group\n");
+		printk(KERN_ERR "THP: failed register hugeage group\n");
 		goto out;
 	}
 #endif
-- 
1.7.4.4

[PATCH 3/4] mm: improve THP printk messages

[Amerigo Wang]

As Andrea suggested, use "THP:" prefix to avoid
being confused with hugetlb.

Signed-off-by: WANG Cong <amwang@redhat.com>
---
 mm/huge_memory.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 126c96b..f9e720c 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -506,7 +506,7 @@ static int __init hugepage_init(void)
 	if (no_hugepage_init) {
 		err = 0;
 		transparent_hugepage_flags = 0;
-		printk(KERN_INFO "hugepage: totally disabled\n");
+		printk(KERN_INFO "THP: totally disabled\n");
 		goto out;
 	}
 
@@ -514,19 +514,19 @@ static int __init hugepage_init(void)
 	err = -ENOMEM;
 	hugepage_kobj = kobject_create_and_add("transparent_hugepage", mm_kobj);
 	if (unlikely(!hugepage_kobj)) {
-		printk(KERN_ERR "hugepage: failed kobject create\n");
+		printk(KERN_ERR "THP: failed kobject create\n");
 		goto out;
 	}
 
 	err = sysfs_create_group(hugepage_kobj, &hugepage_attr_group);
 	if (err) {
-		printk(KERN_ERR "hugepage: failed register hugeage group\n");
+		printk(KERN_ERR "THP: failed register hugeage group\n");
 		goto out;
 	}
 
 	err = sysfs_create_group(hugepage_kobj, &khugepaged_attr_group);
 	if (err) {
-		printk(KERN_ERR "hugepage: failed register hugeage group\n");
+		printk(KERN_ERR "THP: failed register hugeage group\n");
 		goto out;
 	}
 #endif
-- 
1.7.4.4

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 3/4] mm: improve THP printk messages

[David Rientjes]

On Tue, 21 Jun 2011, Amerigo Wang wrote:

> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 126c96b..f9e720c 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -506,7 +506,7 @@ static int __init hugepage_init(void)
>  	if (no_hugepage_init) {
>  		err = 0;
>  		transparent_hugepage_flags = 0;
> -		printk(KERN_INFO "hugepage: totally disabled\n");
> +		printk(KERN_INFO "THP: totally disabled\n");
>  		goto out;
>  	}
>  
> @@ -514,19 +514,19 @@ static int __init hugepage_init(void)
>  	err = -ENOMEM;
>  	hugepage_kobj = kobject_create_and_add("transparent_hugepage", mm_kobj);
>  	if (unlikely(!hugepage_kobj)) {
> -		printk(KERN_ERR "hugepage: failed kobject create\n");
> +		printk(KERN_ERR "THP: failed kobject create\n");
>  		goto out;
>  	}
>  
>  	err = sysfs_create_group(hugepage_kobj, &hugepage_attr_group);
>  	if (err) {
> -		printk(KERN_ERR "hugepage: failed register hugeage group\n");
> +		printk(KERN_ERR "THP: failed register hugeage group\n");
>  		goto out;
>  	}
>  
>  	err = sysfs_create_group(hugepage_kobj, &khugepaged_attr_group);
>  	if (err) {
> -		printk(KERN_ERR "hugepage: failed register hugeage group\n");
> +		printk(KERN_ERR "THP: failed register hugeage group\n");
>  		goto out;
>  	}
>  #endif

You're changing a printk() but not fixing the typos in it?

Re: [PATCH 3/4] mm: improve THP printk messages

[David Rientjes]

On Tue, 21 Jun 2011, Amerigo Wang wrote:

> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 126c96b..f9e720c 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -506,7 +506,7 @@ static int __init hugepage_init(void)
>  	if (no_hugepage_init) {
>  		err = 0;
>  		transparent_hugepage_flags = 0;
> -		printk(KERN_INFO "hugepage: totally disabled\n");
> +		printk(KERN_INFO "THP: totally disabled\n");
>  		goto out;
>  	}
>  
> @@ -514,19 +514,19 @@ static int __init hugepage_init(void)
>  	err = -ENOMEM;
>  	hugepage_kobj = kobject_create_and_add("transparent_hugepage", mm_kobj);
>  	if (unlikely(!hugepage_kobj)) {
> -		printk(KERN_ERR "hugepage: failed kobject create\n");
> +		printk(KERN_ERR "THP: failed kobject create\n");
>  		goto out;
>  	}
>  
>  	err = sysfs_create_group(hugepage_kobj, &hugepage_attr_group);
>  	if (err) {
> -		printk(KERN_ERR "hugepage: failed register hugeage group\n");
> +		printk(KERN_ERR "THP: failed register hugeage group\n");
>  		goto out;
>  	}
>  
>  	err = sysfs_create_group(hugepage_kobj, &khugepaged_attr_group);
>  	if (err) {
> -		printk(KERN_ERR "hugepage: failed register hugeage group\n");
> +		printk(KERN_ERR "THP: failed register hugeage group\n");
>  		goto out;
>  	}
>  #endif

You're changing a printk() but not fixing the typos in it?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 3/4] mm: improve THP printk messages

[Cong Wang]

于 2011年06月22日 09:23, David Rientjes 写道:
> You're changing a printk() but not fixing the typos in it?

Oh, sorry, I was not aware of that.

Re: [PATCH 3/4] mm: improve THP printk messages

[Cong Wang]

ao? 2011a1'06ae??22ae?JPY 09:23, David Rientjes a??e??:
> You're changing a printk() but not fixing the typos in it?

Oh, sorry, I was not aware of that.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH 4/4] mm: introduce no_ksm to disable totally KSM

[Amerigo Wang]

Introduce a new kernel parameter "no_ksm" to totally disable KSM.

Signed-off-by: WANG Cong <amwang@redhat.com>
---
 mm/ksm.c |   13 +++++++++++++
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/mm/ksm.c b/mm/ksm.c
index 9a68b0c..eeb45a2 100644
--- a/mm/ksm.c
+++ b/mm/ksm.c
@@ -1984,11 +1984,24 @@ static struct attribute_group ksm_attr_group = {
 };
 #endif /* CONFIG_SYSFS */
 
+static int no_ksm;
+static int __init setup_ksm(char *str)
+{
+	no_ksm = 1;
+	return 0;
+}
+__setup("no_ksm", setup_ksm);
+
 static int __init ksm_init(void)
 {
 	struct task_struct *ksm_thread;
 	int err;
 
+	if (no_ksm) {
+		printk(KERN_INFO "ksm: disabled by cmdline\n");
+		return 0;
+	}
+
 	err = ksm_slab_init();
 	if (err)
 		goto out;
-- 
1.7.4.4

[PATCH 4/4] mm: introduce no_ksm to disable totally KSM

[Amerigo Wang]

Introduce a new kernel parameter "no_ksm" to totally disable KSM.

Signed-off-by: WANG Cong <amwang@redhat.com>
---
 mm/ksm.c |   13 +++++++++++++
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/mm/ksm.c b/mm/ksm.c
index 9a68b0c..eeb45a2 100644
--- a/mm/ksm.c
+++ b/mm/ksm.c
@@ -1984,11 +1984,24 @@ static struct attribute_group ksm_attr_group = {
 };
 #endif /* CONFIG_SYSFS */
 
+static int no_ksm;
+static int __init setup_ksm(char *str)
+{
+	no_ksm = 1;
+	return 0;
+}
+__setup("no_ksm", setup_ksm);
+
 static int __init ksm_init(void)
 {
 	struct task_struct *ksm_thread;
 	int err;
 
+	if (no_ksm) {
+		printk(KERN_INFO "ksm: disabled by cmdline\n");
+		return 0;
+	}
+
 	err = ksm_slab_init();
 	if (err)
 		goto out;
-- 
1.7.4.4

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 4/4] mm: introduce no_ksm to disable totally KSM

[Andrea Arcangeli]

On Tue, Jun 21, 2011 at 04:10:45PM +0800, Amerigo Wang wrote:
> Introduce a new kernel parameter "no_ksm" to totally disable KSM.

Here as well this is the wrong approach. If you want to save memory,
you should make ksmd quit when run=0 and start only when setting
ksm/run=1. And move the daemon hashes and slabs initializations to the
ksmd daemon start. Not registering in sysfs and crippling down the
feature despite you loaded the proper .text into memory isn't good.

Re: [PATCH 4/4] mm: introduce no_ksm to disable totally KSM

[Andrea Arcangeli]

On Tue, Jun 21, 2011 at 04:10:45PM +0800, Amerigo Wang wrote:
> Introduce a new kernel parameter "no_ksm" to totally disable KSM.

Here as well this is the wrong approach. If you want to save memory,
you should make ksmd quit when run=0 and start only when setting
ksm/run=1. And move the daemon hashes and slabs initializations to the
ksmd daemon start. Not registering in sysfs and crippling down the
feature despite you loaded the proper .text into memory isn't good.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 4/4] mm: introduce no_ksm to disable totally KSM

[Cong Wang]

于 2011年06月21日 21:32, Andrea Arcangeli 写道:
> On Tue, Jun 21, 2011 at 04:10:45PM +0800, Amerigo Wang wrote:
>> Introduce a new kernel parameter "no_ksm" to totally disable KSM.
>
> Here as well this is the wrong approach. If you want to save memory,
> you should make ksmd quit when run=0 and start only when setting
> ksm/run=1. And move the daemon hashes and slabs initializations to the
> ksmd daemon start. Not registering in sysfs and crippling down the
> feature despite you loaded the proper .text into memory isn't good.

1. Not only about saving memory, as I explained in other thread.

2. Recompiling kernel is not always acceptable, as I replied in other thread.

Re: [PATCH 4/4] mm: introduce no_ksm to disable totally KSM

[Cong Wang]

ao? 2011a1'06ae??21ae?JPY 21:32, Andrea Arcangeli a??e??:
> On Tue, Jun 21, 2011 at 04:10:45PM +0800, Amerigo Wang wrote:
>> Introduce a new kernel parameter "no_ksm" to totally disable KSM.
>
> Here as well this is the wrong approach. If you want to save memory,
> you should make ksmd quit when run=0 and start only when setting
> ksm/run=1. And move the daemon hashes and slabs initializations to the
> ksmd daemon start. Not registering in sysfs and crippling down the
> feature despite you loaded the proper .text into memory isn't good.

1. Not only about saving memory, as I explained in other thread.

2. Recompiling kernel is not always acceptable, as I replied in other thread.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 1/4] mm: completely disable THP by transparent_hugepage=0

[Michal Hocko]

On Tue 21-06-11 16:10:42, Amerigo Wang wrote:
> Introduce "transparent_hugepage=0" to totally disable THP.
> "transparent_hugepage=never" means setting THP to be partially
> disabled, we need a new way to totally disable it.

I am wondering why would you like to disable the feature on per-boot
basis. Does transparent_hugepage=never bring any measurable overhead?

-- 
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9    
Czech Republic

Re: [PATCH v2 1/4] mm: completely disable THP by transparent_hugepage=0

[Michal Hocko]

On Tue 21-06-11 16:10:42, Amerigo Wang wrote:
> Introduce "transparent_hugepage=0" to totally disable THP.
> "transparent_hugepage=never" means setting THP to be partially
> disabled, we need a new way to totally disable it.

I am wondering why would you like to disable the feature on per-boot
basis. Does transparent_hugepage=never bring any measurable overhead?

-- 
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9    
Czech Republic

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 1/4] mm: completely disable THP by transparent_hugepage=0

[Michal Hocko]

On Tue 21-06-11 13:52:02, Michal Hocko wrote:
> On Tue 21-06-11 16:10:42, Amerigo Wang wrote:
> > Introduce "transparent_hugepage=0" to totally disable THP.
> > "transparent_hugepage=never" means setting THP to be partially
> > disabled, we need a new way to totally disable it.
> 
> I am wondering why would you like to disable the feature on per-boot
> basis. Does transparent_hugepage=never bring any measurable overhead?

just found https://lkml.org/lkml/2011/6/20/245

-- 
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9    
Czech Republic

Re: [PATCH v2 1/4] mm: completely disable THP by transparent_hugepage=0

[Michal Hocko]

On Tue 21-06-11 13:52:02, Michal Hocko wrote:
> On Tue 21-06-11 16:10:42, Amerigo Wang wrote:
> > Introduce "transparent_hugepage=0" to totally disable THP.
> > "transparent_hugepage=never" means setting THP to be partially
> > disabled, we need a new way to totally disable it.
> 
> I am wondering why would you like to disable the feature on per-boot
> basis. Does transparent_hugepage=never bring any measurable overhead?

just found https://lkml.org/lkml/2011/6/20/245

-- 
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9    
Czech Republic

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 1/4] mm: completely disable THP by transparent_hugepage=0

[Andrea Arcangeli]

On Tue, Jun 21, 2011 at 04:10:42PM +0800, Amerigo Wang wrote:
> Introduce "transparent_hugepage=0" to totally disable THP.
> "transparent_hugepage=never" means setting THP to be partially
> disabled, we need a new way to totally disable it.
> 

I think I already clarified this is not worth it. Removing sysfs
registration is just pointless. If you really want to save ~8k of RAM,
at most you can try to move the init of the khugepaged slots hash and
the kmem_cache_init to the khugepaged deamon start but even that isn't
so useful. Not registering into sysfs is just pointless and it's a
gratuitous loss of a feature.

Re: [PATCH v2 1/4] mm: completely disable THP by transparent_hugepage=0

[Andrea Arcangeli]

On Tue, Jun 21, 2011 at 04:10:42PM +0800, Amerigo Wang wrote:
> Introduce "transparent_hugepage=0" to totally disable THP.
> "transparent_hugepage=never" means setting THP to be partially
> disabled, we need a new way to totally disable it.
> 

I think I already clarified this is not worth it. Removing sysfs
registration is just pointless. If you really want to save ~8k of RAM,
at most you can try to move the init of the khugepaged slots hash and
the kmem_cache_init to the khugepaged deamon start but even that isn't
so useful. Not registering into sysfs is just pointless and it's a
gratuitous loss of a feature.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 1/4] mm: completely disable THP by transparent_hugepage=0

[Cong Wang]

于 2011年06月21日 21:30, Andrea Arcangeli 写道:
> On Tue, Jun 21, 2011 at 04:10:42PM +0800, Amerigo Wang wrote:
>> Introduce "transparent_hugepage=0" to totally disable THP.
>> "transparent_hugepage=never" means setting THP to be partially
>> disabled, we need a new way to totally disable it.
>>
>
> I think I already clarified this is not worth it. Removing sysfs
> registration is just pointless. If you really want to save ~8k of RAM,
> at most you can try to move the init of the khugepaged slots hash and
> the kmem_cache_init to the khugepaged deamon start but even that isn't
> so useful. Not registering into sysfs is just pointless and it's a
> gratuitous loss of a feature.

Sorry, I replied to you in the other thread, so I don't want to dup
it here.

Re: [PATCH v2 1/4] mm: completely disable THP by transparent_hugepage=0

[Cong Wang]

ao? 2011a1'06ae??21ae?JPY 21:30, Andrea Arcangeli a??e??:
> On Tue, Jun 21, 2011 at 04:10:42PM +0800, Amerigo Wang wrote:
>> Introduce "transparent_hugepage=0" to totally disable THP.
>> "transparent_hugepage=never" means setting THP to be partially
>> disabled, we need a new way to totally disable it.
>>
>
> I think I already clarified this is not worth it. Removing sysfs
> registration is just pointless. If you really want to save ~8k of RAM,
> at most you can try to move the init of the khugepaged slots hash and
> the kmem_cache_init to the khugepaged deamon start but even that isn't
> so useful. Not registering into sysfs is just pointless and it's a
> gratuitous loss of a feature.

Sorry, I replied to you in the other thread, so I don't want to dup
it here.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 1/4] mm: completely disable THP by transparent_hugepage=0

[David Rientjes]

On Tue, 21 Jun 2011, Amerigo Wang wrote:

> Introduce "transparent_hugepage=0" to totally disable THP.
> "transparent_hugepage=never" means setting THP to be partially
> disabled, we need a new way to totally disable it.
> 

Why can't you just compile it off so you never even compile 
mm/huge_memory.c in the first place and save the space in the kernel image 
as well?  Having the interface available to enable the feature at runtime 
is worth the savings this patch provides, in my opinion.

Re: [PATCH v2 1/4] mm: completely disable THP by transparent_hugepage=0

[David Rientjes]

On Tue, 21 Jun 2011, Amerigo Wang wrote:

> Introduce "transparent_hugepage=0" to totally disable THP.
> "transparent_hugepage=never" means setting THP to be partially
> disabled, we need a new way to totally disable it.
> 

Why can't you just compile it off so you never even compile 
mm/huge_memory.c in the first place and save the space in the kernel image 
as well?  Having the interface available to enable the feature at runtime 
is worth the savings this patch provides, in my opinion.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 1/4] mm: completely disable THP by transparent_hugepage=0

[Cong Wang]

于 2011年06月22日 09:16, David Rientjes 写道:
> On Tue, 21 Jun 2011, Amerigo Wang wrote:
>
>> Introduce "transparent_hugepage=0" to totally disable THP.
>> "transparent_hugepage=never" means setting THP to be partially
>> disabled, we need a new way to totally disable it.
>>
>
> Why can't you just compile it off so you never even compile
> mm/huge_memory.c in the first place and save the space in the kernel image
> as well?  Having the interface available to enable the feature at runtime
> is worth the savings this patch provides, in my opinion.

https://lkml.org/lkml/2011/6/20/506

Re: [PATCH v2 1/4] mm: completely disable THP by transparent_hugepage=0

[Cong Wang]

ao? 2011a1'06ae??22ae?JPY 09:16, David Rientjes a??e??:
> On Tue, 21 Jun 2011, Amerigo Wang wrote:
>
>> Introduce "transparent_hugepage=0" to totally disable THP.
>> "transparent_hugepage=never" means setting THP to be partially
>> disabled, we need a new way to totally disable it.
>>
>
> Why can't you just compile it off so you never even compile
> mm/huge_memory.c in the first place and save the space in the kernel image
> as well?  Having the interface available to enable the feature at runtime
> is worth the savings this patch provides, in my opinion.

https://lkml.org/lkml/2011/6/20/506

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 1/4] mm: completely disable THP by transparent_hugepage=0

[David Rientjes]

On Wed, 22 Jun 2011, Cong Wang wrote:

> > > Introduce "transparent_hugepage=0" to totally disable THP.
> > > "transparent_hugepage=never" means setting THP to be partially
> > > disabled, we need a new way to totally disable it.
> > > 
> > 
> > Why can't you just compile it off so you never even compile
> > mm/huge_memory.c in the first place and save the space in the kernel image
> > as well?  Having the interface available to enable the feature at runtime
> > is worth the savings this patch provides, in my opinion.
> 
> https://lkml.org/lkml/2011/6/20/506
> 

If you're proposing a patch for a specific purpose, it's appropriate to 
include that in the changelog.

But now that I know what you're proposing this for, it's an easy NACK: 
transparent_hugepage=0 has no significant benefit over 
transparent_hugepage=never for kdump because the memory savings is 
negligible.

Re: [PATCH v2 1/4] mm: completely disable THP by transparent_hugepage=0

[David Rientjes]

On Wed, 22 Jun 2011, Cong Wang wrote:

> > > Introduce "transparent_hugepage=0" to totally disable THP.
> > > "transparent_hugepage=never" means setting THP to be partially
> > > disabled, we need a new way to totally disable it.
> > > 
> > 
> > Why can't you just compile it off so you never even compile
> > mm/huge_memory.c in the first place and save the space in the kernel image
> > as well?  Having the interface available to enable the feature at runtime
> > is worth the savings this patch provides, in my opinion.
> 
> https://lkml.org/lkml/2011/6/20/506
> 

If you're proposing a patch for a specific purpose, it's appropriate to 
include that in the changelog.

But now that I know what you're proposing this for, it's an easy NACK: 
transparent_hugepage=0 has no significant benefit over 
transparent_hugepage=never for kdump because the memory savings is 
negligible.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 1/4] mm: completely disable THP by transparent_hugepage=0

[Cong Wang]

于 2011年06月22日 11:24, David Rientjes 写道:
> On Wed, 22 Jun 2011, Cong Wang wrote:
>
>>>> Introduce "transparent_hugepage=0" to totally disable THP.
>>>> "transparent_hugepage=never" means setting THP to be partially
>>>> disabled, we need a new way to totally disable it.
>>>>
>>>
>>> Why can't you just compile it off so you never even compile
>>> mm/huge_memory.c in the first place and save the space in the kernel image
>>> as well?  Having the interface available to enable the feature at runtime
>>> is worth the savings this patch provides, in my opinion.
>>
>> https://lkml.org/lkml/2011/6/20/506
>>
>
> If you're proposing a patch for a specific purpose, it's appropriate to
> include that in the changelog.

Sorry, I can't put everything you don't see into the changelog.

>
> But now that I know what you're proposing this for, it's an easy NACK:
> transparent_hugepage=0 has no significant benefit over
> transparent_hugepage=never for kdump because the memory savings is
> negligible.

I hate to repeat things, sorry, please go for the other thread where I
replied to Andrea.

Re: [PATCH v2 1/4] mm: completely disable THP by transparent_hugepage=0

[Cong Wang]

ao? 2011a1'06ae??22ae?JPY 11:24, David Rientjes a??e??:
> On Wed, 22 Jun 2011, Cong Wang wrote:
>
>>>> Introduce "transparent_hugepage=0" to totally disable THP.
>>>> "transparent_hugepage=never" means setting THP to be partially
>>>> disabled, we need a new way to totally disable it.
>>>>
>>>
>>> Why can't you just compile it off so you never even compile
>>> mm/huge_memory.c in the first place and save the space in the kernel image
>>> as well?  Having the interface available to enable the feature at runtime
>>> is worth the savings this patch provides, in my opinion.
>>
>> https://lkml.org/lkml/2011/6/20/506
>>
>
> If you're proposing a patch for a specific purpose, it's appropriate to
> include that in the changelog.

Sorry, I can't put everything you don't see into the changelog.

>
> But now that I know what you're proposing this for, it's an easy NACK:
> transparent_hugepage=0 has no significant benefit over
> transparent_hugepage=never for kdump because the memory savings is
> negligible.

I hate to repeat things, sorry, please go for the other thread where I
replied to Andrea.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 1/4] mm: completely disable THP by transparent_hugepage=0

[David Rientjes]

On Wed, 22 Jun 2011, Cong Wang wrote:

> > If you're proposing a patch for a specific purpose, it's appropriate to
> > include that in the changelog.
> 
> Sorry, I can't put everything you don't see into the changelog.
> 

As far as changelogs go, yes, we can demand that.

> > 
> > But now that I know what you're proposing this for, it's an easy NACK:
> > transparent_hugepage=0 has no significant benefit over
> > transparent_hugepage=never for kdump because the memory savings is
> > negligible.
> 
> I hate to repeat things, sorry, please go for the other thread where I
> replied to Andrea.
> 

All of this needs to be in the changelog if you want your patches to even 
be considered, thanks.

Re: [PATCH v2 1/4] mm: completely disable THP by transparent_hugepage=0

[David Rientjes]

On Wed, 22 Jun 2011, Cong Wang wrote:

> > If you're proposing a patch for a specific purpose, it's appropriate to
> > include that in the changelog.
> 
> Sorry, I can't put everything you don't see into the changelog.
> 

As far as changelogs go, yes, we can demand that.

> > 
> > But now that I know what you're proposing this for, it's an easy NACK:
> > transparent_hugepage=0 has no significant benefit over
> > transparent_hugepage=never for kdump because the memory savings is
> > negligible.
> 
> I hate to repeat things, sorry, please go for the other thread where I
> replied to Andrea.
> 

All of this needs to be in the changelog if you want your patches to even 
be considered, thanks.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH v2 1/4] mm: completely disable THP by transparent_hugepage=0

[Cong Wang]

于 2011年06月22日 14:23, David Rientjes 写道:
> All of this needs to be in the changelog if you want your patches to even
> be considered, thanks.

Ok, thanks for reminding.

Re: [PATCH v2 1/4] mm: completely disable THP by transparent_hugepage=0

[Cong Wang]

ao? 2011a1'06ae??22ae?JPY 14:23, David Rientjes a??e??:
> All of this needs to be in the changelog if you want your patches to even
> be considered, thanks.

Ok, thanks for reminding.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>