* [PATCH] hugetlbfs: correct handling of negative input to /proc/sys/vm/nr_hugepages
@ 2011-02-21 15:47 Petr Holasek
2011-02-22 0:30 ` Naoya Horiguchi
2011-02-22 10:02 ` Mel Gorman
0 siblings, 2 replies; 6+ messages in thread
From: Petr Holasek @ 2011-02-21 15:47 UTC (permalink / raw)
To: linux-kernel
Cc: Petr Holasek, Andi Kleen, Naoya Horiguchi, Mel Gorman,
Andrew Morton, Wu Fengguang, linux-mm
When user insert negative value into /proc/sys/vm/nr_hugepages it will result
in the setting a random number of HugePages in system (can be easily showed
at /proc/meminfo output). This patch fixes the wrong behavior so that the
negative input will result in nr_hugepages value unchanged.
Signed-off-by: Petr Holasek <pholasek@redhat.com>
---
mm/hugetlb.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index bb0b7c1..f99d7a8 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1872,8 +1872,7 @@ static int hugetlb_sysctl_handler_common(bool obey_mempolicy,
unsigned long tmp;
int ret;
- if (!write)
- tmp = h->max_huge_pages;
+ tmp = h->max_huge_pages;
if (write && h->order >= MAX_ORDER)
return -EINVAL;
--
1.7.1
--
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>
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] hugetlbfs: correct handling of negative input to /proc/sys/vm/nr_hugepages
2011-02-21 15:47 [PATCH] hugetlbfs: correct handling of negative input to /proc/sys/vm/nr_hugepages Petr Holasek
@ 2011-02-22 0:30 ` Naoya Horiguchi
2011-02-22 10:02 ` Mel Gorman
1 sibling, 0 replies; 6+ messages in thread
From: Naoya Horiguchi @ 2011-02-22 0:30 UTC (permalink / raw)
To: Petr Holasek
Cc: linux-kernel, Andi Kleen, Mel Gorman, Andrew Morton, Wu Fengguang,
linux-mm
On Mon, Feb 21, 2011 at 04:47:49PM +0100, Petr Holasek wrote:
> When user insert negative value into /proc/sys/vm/nr_hugepages it will result
> in the setting a random number of HugePages in system (can be easily showed
> at /proc/meminfo output). This patch fixes the wrong behavior so that the
> negative input will result in nr_hugepages value unchanged.
>
> Signed-off-by: Petr Holasek <pholasek@redhat.com>
> ---
> mm/hugetlb.c | 3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index bb0b7c1..f99d7a8 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -1872,8 +1872,7 @@ static int hugetlb_sysctl_handler_common(bool obey_mempolicy,
> unsigned long tmp;
> int ret;
>
> - if (!write)
> - tmp = h->max_huge_pages;
> + tmp = h->max_huge_pages;
Looks reasonable.
hugetlb_overcommit_handler() has the same wrong behavior.
So how about fixing that too?
Anyway,
Reviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.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>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] hugetlbfs: correct handling of negative input to /proc/sys/vm/nr_hugepages
2011-02-21 15:47 [PATCH] hugetlbfs: correct handling of negative input to /proc/sys/vm/nr_hugepages Petr Holasek
2011-02-22 0:30 ` Naoya Horiguchi
@ 2011-02-22 10:02 ` Mel Gorman
2011-02-24 0:18 ` Andrew Morton
1 sibling, 1 reply; 6+ messages in thread
From: Mel Gorman @ 2011-02-22 10:02 UTC (permalink / raw)
To: Petr Holasek
Cc: linux-kernel, Andi Kleen, Naoya Horiguchi, Andrew Morton,
Wu Fengguang, linux-mm
On Mon, Feb 21, 2011 at 04:47:49PM +0100, Petr Holasek wrote:
> When user insert negative value into /proc/sys/vm/nr_hugepages it will result
> in the setting a random number of HugePages in system (can be easily showed
> at /proc/meminfo output).
I bet you a shiny penny that the value of HugePages becomes the maximum
number that could be allocated by the system at the time rather than a
random value.
> This patch fixes the wrong behavior so that the
> negative input will result in nr_hugepages value unchanged.
>
As pointed out elsewhere, nr_overcommit_hugepages also needs fixing but
the fix is essentially the same.
> Signed-off-by: Petr Holasek <pholasek@redhat.com>
> ---
> mm/hugetlb.c | 3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index bb0b7c1..f99d7a8 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -1872,8 +1872,7 @@ static int hugetlb_sysctl_handler_common(bool obey_mempolicy,
> unsigned long tmp;
> int ret;
>
> - if (!write)
> - tmp = h->max_huge_pages;
> + tmp = h->max_huge_pages;
>
> if (write && h->order >= MAX_ORDER)
> return -EINVAL;
> --
> 1.7.1
>
--
Mel Gorman
SUSE Labs
--
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>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] hugetlbfs: correct handling of negative input to /proc/sys/vm/nr_hugepages
2011-02-22 10:02 ` Mel Gorman
@ 2011-02-24 0:18 ` Andrew Morton
2011-02-24 9:49 ` Mel Gorman
0 siblings, 1 reply; 6+ messages in thread
From: Andrew Morton @ 2011-02-24 0:18 UTC (permalink / raw)
To: Mel Gorman
Cc: Petr Holasek, linux-kernel, Andi Kleen, Naoya Horiguchi,
Wu Fengguang, linux-mm
On Tue, 22 Feb 2011 10:02:36 +0000
Mel Gorman <mel@csn.ul.ie> wrote:
> On Mon, Feb 21, 2011 at 04:47:49PM +0100, Petr Holasek wrote:
> > When user insert negative value into /proc/sys/vm/nr_hugepages it will result
> > in the setting a random number of HugePages in system (can be easily showed
> > at /proc/meminfo output).
>
> I bet you a shiny penny that the value of HugePages becomes the maximum
> number that could be allocated by the system at the time rather than a
> random value.
That seems to be the case from my reading. In which case the patch
removes probably-undocumented and possibly-useful existing behavior.
--
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>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] hugetlbfs: correct handling of negative input to /proc/sys/vm/nr_hugepages
2011-02-24 0:18 ` Andrew Morton
@ 2011-02-24 9:49 ` Mel Gorman
2011-02-24 18:20 ` Eric B Munson
0 siblings, 1 reply; 6+ messages in thread
From: Mel Gorman @ 2011-02-24 9:49 UTC (permalink / raw)
To: Andrew Morton
Cc: Petr Holasek, linux-kernel, Andi Kleen, Naoya Horiguchi,
Wu Fengguang, linux-mm
On Wed, Feb 23, 2011 at 04:18:18PM -0800, Andrew Morton wrote:
> On Tue, 22 Feb 2011 10:02:36 +0000
> Mel Gorman <mel@csn.ul.ie> wrote:
>
> > On Mon, Feb 21, 2011 at 04:47:49PM +0100, Petr Holasek wrote:
> > > When user insert negative value into /proc/sys/vm/nr_hugepages it will result
> > > in the setting a random number of HugePages in system (can be easily showed
> > > at /proc/meminfo output).
> >
> > I bet you a shiny penny that the value of HugePages becomes the maximum
> > number that could be allocated by the system at the time rather than a
> > random value.
>
> That seems to be the case from my reading. In which case the patch
> removes probably-undocumented and possibly-useful existing behavior.
>
It's not proof that no one does this but I'm not aware of any documentation
related to hugetlbfs that recommends writing negative values to take advantage
of this side-effect. It's more likely they simply wrote a very large number
to nr_hugepages if they wanted "as many hugepages as possible" as it makes
more intuitive sense than asking for a negative amount of pages. hugeadm at
least is not depending on this behaviour AFAIK.
--
Mel Gorman
SUSE Labs
--
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>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] hugetlbfs: correct handling of negative input to /proc/sys/vm/nr_hugepages
2011-02-24 9:49 ` Mel Gorman
@ 2011-02-24 18:20 ` Eric B Munson
0 siblings, 0 replies; 6+ messages in thread
From: Eric B Munson @ 2011-02-24 18:20 UTC (permalink / raw)
To: Mel Gorman
Cc: Andrew Morton, Petr Holasek, linux-kernel, Andi Kleen,
Naoya Horiguchi, Wu Fengguang, linux-mm
[-- Attachment #1: Type: text/plain, Size: 1348 bytes --]
On Thu, 24 Feb 2011, Mel Gorman wrote:
> On Wed, Feb 23, 2011 at 04:18:18PM -0800, Andrew Morton wrote:
> > On Tue, 22 Feb 2011 10:02:36 +0000
> > Mel Gorman <mel@csn.ul.ie> wrote:
> >
> > > On Mon, Feb 21, 2011 at 04:47:49PM +0100, Petr Holasek wrote:
> > > > When user insert negative value into /proc/sys/vm/nr_hugepages it will result
> > > > in the setting a random number of HugePages in system (can be easily showed
> > > > at /proc/meminfo output).
> > >
> > > I bet you a shiny penny that the value of HugePages becomes the maximum
> > > number that could be allocated by the system at the time rather than a
> > > random value.
> >
> > That seems to be the case from my reading. In which case the patch
> > removes probably-undocumented and possibly-useful existing behavior.
> >
>
> It's not proof that no one does this but I'm not aware of any documentation
> related to hugetlbfs that recommends writing negative values to take advantage
> of this side-effect. It's more likely they simply wrote a very large number
> to nr_hugepages if they wanted "as many hugepages as possible" as it makes
> more intuitive sense than asking for a negative amount of pages. hugeadm at
> least is not depending on this behaviour AFAIK.
That is correct, hugeadm never writes negative values to huge page pool sizes.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-02-24 18:22 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-02-21 15:47 [PATCH] hugetlbfs: correct handling of negative input to /proc/sys/vm/nr_hugepages Petr Holasek
2011-02-22 0:30 ` Naoya Horiguchi
2011-02-22 10:02 ` Mel Gorman
2011-02-24 0:18 ` Andrew Morton
2011-02-24 9:49 ` Mel Gorman
2011-02-24 18:20 ` Eric B Munson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).