just not used. However,
that bad range is used in kernel 2.6.32 to initialize the old boot
memory allocator, which causes a crash during boot.
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
Cc: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
Cc: Yinghai Lu ying...@kernel.org
Acked
On Mon, 15 Sep 2014 17:13:39 -0700 (PDT)
David Rientjes rient...@google.com wrote:
On Mon, 15 Sep 2014, Luiz Capitulino wrote:
The setup_node_data() function allocates a pg_data_t object, inserts it
into the node_data[] array and initializes the following fields: node_id,
node_start_pfn
On Tue, 8 Jul 2014 15:11:13 -0700
Andrew Morton wrote:
> On Wed, 2 Jul 2014 17:44:46 -0700 (PDT) David Rientjes
> wrote:
>
> > > > @@ -2248,36 +2257,18 @@ static int hugetlb_sysctl_handler_common(bool
> > > > obey_mempolicy,
> > > > void __user *buffer, size_t
On Tue, 8 Jul 2014 15:11:13 -0700
Andrew Morton a...@linux-foundation.org wrote:
On Wed, 2 Jul 2014 17:44:46 -0700 (PDT) David Rientjes rient...@google.com
wrote:
@@ -2248,36 +2257,18 @@ static int hugetlb_sysctl_handler_common(bool
obey_mempolicy,
void
machine and Linux
as a numa guest on hyperv and qemu/kvm.
PS: The wrong memory range reported by setup_node_data() seems to be
harmless in the current kernel because it's just not used. However,
that bad range is used in kernel 2.6.32 to initialize the old boot
memory allocator, which ca
() seems to be
harmless in the current kernel because it's just not used. However,
that bad range is used in kernel 2.6.32 to initialize the old boot
memory allocator, which causes a crash during boot.
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
v2
- Restore Initmem text
On Wed, 2 Jul 2014 16:20:47 -0700 (PDT)
David Rientjes wrote:
> On Wed, 2 Jul 2014, Luiz Capitulino wrote:
>
> > > With this patch, the dmesg changes break one of my scripts that we use to
> > > determine the start and end address of a node (doubly bad because there's
On Wed, 2 Jul 2014 17:44:46 -0700 (PDT)
David Rientjes wrote:
> On Wed, 2 Jul 2014, Luiz Capitulino wrote:
>
> > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> > > --- a/mm/hugetlb.c
> > > +++ b/mm/hugetlb.c
> > > @@ -1734,21 +1734,13 @@ stat
On Mon, 30 Jun 2014 17:46:35 -0700 (PDT)
David Rientjes wrote:
> They are unnecessary: "zero" can be used in place of "hugetlb_zero" and
> passing extra2 == NULL is equivalent to infinity.
>
> Signed-off-by: David Rientjes
Reviewed-by: Luiz Capitulino
>
On Mon, 30 Jun 2014 16:57:06 -0700 (PDT)
David Rientjes wrote:
> Three different interfaces alter the maximum number of hugepages for an
> hstate:
>
> - /proc/sys/vm/nr_hugepages for global number of hugepages of the default
>hstate,
>
> -
On Mon, 30 Jun 2014 16:42:39 -0700 (PDT)
David Rientjes wrote:
> On Thu, 19 Jun 2014, Luiz Capitulino wrote:
>
> > The setup_node_data() function allocates a pg_data_t object, inserts it
> > into the node_data[] array and initializes the following fields:
> >
On Mon, 30 Jun 2014 16:42:39 -0700 (PDT)
David Rientjes rient...@google.com wrote:
On Thu, 19 Jun 2014, Luiz Capitulino wrote:
The setup_node_data() function allocates a pg_data_t object, inserts it
into the node_data[] array and initializes the following fields:
node_id, node_start_pfn
On Mon, 30 Jun 2014 16:57:06 -0700 (PDT)
David Rientjes rient...@google.com wrote:
Three different interfaces alter the maximum number of hugepages for an
hstate:
- /proc/sys/vm/nr_hugepages for global number of hugepages of the default
hstate,
-
On Mon, 30 Jun 2014 17:46:35 -0700 (PDT)
David Rientjes rient...@google.com wrote:
They are unnecessary: zero can be used in place of hugetlb_zero and
passing extra2 == NULL is equivalent to infinity.
Signed-off-by: David Rientjes rient...@google.com
Reviewed-by: Luiz Capitulino lcapitul
On Wed, 2 Jul 2014 16:20:47 -0700 (PDT)
David Rientjes rient...@google.com wrote:
On Wed, 2 Jul 2014, Luiz Capitulino wrote:
With this patch, the dmesg changes break one of my scripts that we use to
determine the start and end address of a node (doubly bad because there's
no sysfs
On Wed, 2 Jul 2014 17:44:46 -0700 (PDT)
David Rientjes rient...@google.com wrote:
On Wed, 2 Jul 2014, Luiz Capitulino wrote:
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1734,21 +1734,13 @@ static ssize_t nr_hugepages_show_common(struct
On Thu, 26 Jun 2014 10:51:11 -0400
Rik van Riel wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 06/19/2014 10:20 PM, Luiz Capitulino wrote:
>
> > @@ -523,8 +508,17 @@ static int __init numa_register_memblks(struct
> > numa_meminfo *mi) en
On Thu, 26 Jun 2014 10:51:11 -0400
Rik van Riel r...@redhat.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/19/2014 10:20 PM, Luiz Capitulino wrote:
@@ -523,8 +508,17 @@ static int __init numa_register_memblks(struct
numa_meminfo *mi) end = max(mi-blk[i].end, end
and Linux
as a numa guest on hyperv and qemu/kvm.
PS: The wrong memory range reported by setup_node_data() seems to be
harmless in the current kernel because it's just not used. However,
that bad range is used in kernel 2.6.32 to initialize the old boot
memory allocator, which causes a cra
to be
harmless in the current kernel because it's just not used. However,
that bad range is used in kernel 2.6.32 to initialize the old boot
memory allocator, which causes a crash during boot.
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
arch/x86/include/asm/numa.h | 1 -
arch
Yinghai, sorry for my late reply.
On Mon, 9 Jun 2014 15:13:41 -0700
Yinghai Lu wrote:
> On Mon, Jun 9, 2014 at 12:03 PM, Luiz Capitulino
> wrote:
> > On Sun, 8 Jun 2014 18:29:11 -0700
> > Yinghai Lu wrote:
> >
> >> On Sun, Jun 8, 2014 at 3:14
Yinghai, sorry for my late reply.
On Mon, 9 Jun 2014 15:13:41 -0700
Yinghai Lu ying...@kernel.org wrote:
On Mon, Jun 9, 2014 at 12:03 PM, Luiz Capitulino lcapitul...@redhat.com
wrote:
On Sun, 8 Jun 2014 18:29:11 -0700
Yinghai Lu ying...@kernel.org wrote:
On Sun, Jun 8, 2014 at 3:14
On Tue, 10 Jun 2014 15:10:01 -0700 (PDT)
David Rientjes wrote:
> On Mon, 9 Jun 2014, Luiz Capitulino wrote:
>
> > > > > > diff --git a/arch/x86/include/asm/numa.h
> > > > > > b/arch/x86/include/asm/numa.h
> > > > > > index 4064aca..
On Tue, 10 Jun 2014 15:10:01 -0700 (PDT)
David Rientjes rient...@google.com wrote:
On Mon, 9 Jun 2014, Luiz Capitulino wrote:
diff --git a/arch/x86/include/asm/numa.h
b/arch/x86/include/asm/numa.h
index 4064aca..01b493e 100644
--- a/arch/x86/include/asm/numa.h
On Mon, 9 Jun 2014 14:57:16 -0700 (PDT)
David Rientjes wrote:
> On Mon, 9 Jun 2014, Luiz Capitulino wrote:
>
> > > > diff --git a/arch/x86/include/asm/numa.h b/arch/x86/include/asm/numa.h
> > > > index 4064aca..01b493e 100644
> > > > --- a/arch/x86
On Sun, 8 Jun 2014 18:29:11 -0700
Yinghai Lu wrote:
> On Sun, Jun 8, 2014 at 3:14 PM, Luiz Capitulino
> wrote:
> > In short, I believe this is just dead code for the upstream kernel but this
> > causes a bug for 2.6.32 based kernels.
> >
> > The setup_node_data()
On Sun, 8 Jun 2014 15:25:50 -0700 (PDT)
David Rientjes wrote:
> On Sun, 8 Jun 2014, Luiz Capitulino wrote:
>
> > diff --git a/arch/x86/include/asm/numa.h b/arch/x86/include/asm/numa.h
> > index 4064aca..01b493e 100644
> > --- a/arch/x86/include/asm/numa.h
> > +++
On Sun, 8 Jun 2014 15:25:50 -0700 (PDT)
David Rientjes rient...@google.com wrote:
On Sun, 8 Jun 2014, Luiz Capitulino wrote:
diff --git a/arch/x86/include/asm/numa.h b/arch/x86/include/asm/numa.h
index 4064aca..01b493e 100644
--- a/arch/x86/include/asm/numa.h
+++ b/arch/x86/include/asm
On Sun, 8 Jun 2014 18:29:11 -0700
Yinghai Lu ying...@kernel.org wrote:
On Sun, Jun 8, 2014 at 3:14 PM, Luiz Capitulino lcapitul...@redhat.com
wrote:
In short, I believe this is just dead code for the upstream kernel but this
causes a bug for 2.6.32 based kernels.
The setup_node_data
On Mon, 9 Jun 2014 14:57:16 -0700 (PDT)
David Rientjes rient...@google.com wrote:
On Mon, 9 Jun 2014, Luiz Capitulino wrote:
diff --git a/arch/x86/include/asm/numa.h b/arch/x86/include/asm/numa.h
index 4064aca..01b493e 100644
--- a/arch/x86/include/asm/numa.h
+++ b/arch/x86
memory range
start address is rounded up, as it will always be greater than what is
reported in the SRAT table. This is true when the 2.6.32 kernel runs as a
HyperV guest on Windows Server 2012. Dropping ZONE_ALIGN solves the
problem there.
Signed-off-by: Luiz Capitulino
---
arch/x86/include/asm/numa
is rounded up, as it will always be greater than what is
reported in the SRAT table. This is true when the 2.6.32 kernel runs as a
HyperV guest on Windows Server 2012. Dropping ZONE_ALIGN solves the
problem there.
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
arch/x86/include/asm/numa.h
On Tue, 22 Apr 2014 14:55:46 -0700
Andrew Morton wrote:
> On Tue, 22 Apr 2014 17:37:26 -0400 Luiz Capitulino
> wrote:
>
> > On Thu, 17 Apr 2014 16:01:10 -0700
> > Andrew Morton wrote:
> >
> > > On Thu, 10 Apr 2014 13:58:40 -0400 Luiz Capitulino
>
On Tue, 22 Apr 2014 14:55:46 -0700
Andrew Morton a...@linux-foundation.org wrote:
On Tue, 22 Apr 2014 17:37:26 -0400 Luiz Capitulino lcapitul...@redhat.com
wrote:
On Thu, 17 Apr 2014 16:01:10 -0700
Andrew Morton a...@linux-foundation.org wrote:
On Thu, 10 Apr 2014 13:58:40 -0400
On Wed, 23 Apr 2014 10:48:27 -0700
Randy Dunlap wrote:
> On 04/23/14 10:41, Luiz Capitulino wrote:
> > On Wed, 23 Apr 2014 10:10:29 -0700
> > Randy Dunlap wrote:
> >
> >> On 04/22/14 15:21, a...@linux-foundation.org wrote:
> >>> The mm-of-the-moment s
On Wed, 23 Apr 2014 10:10:29 -0700
Randy Dunlap wrote:
> On 04/22/14 15:21, a...@linux-foundation.org wrote:
> > The mm-of-the-moment snapshot 2014-04-22-15-20 has been uploaded to
> >
> >http://www.ozlabs.org/~akpm/mmotm/
> >
> > mmotm-readme.txt says
> >
> > README for mm-of-the-moment:
On Wed, 23 Apr 2014 10:10:29 -0700
Randy Dunlap rdun...@infradead.org wrote:
On 04/22/14 15:21, a...@linux-foundation.org wrote:
The mm-of-the-moment snapshot 2014-04-22-15-20 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for
On Wed, 23 Apr 2014 10:48:27 -0700
Randy Dunlap rdun...@infradead.org wrote:
On 04/23/14 10:41, Luiz Capitulino wrote:
On Wed, 23 Apr 2014 10:10:29 -0700
Randy Dunlap rdun...@infradead.org wrote:
On 04/22/14 15:21, a...@linux-foundation.org wrote:
The mm-of-the-moment snapshot 2014-04
On Thu, 17 Apr 2014 16:01:10 -0700
Andrew Morton wrote:
> On Thu, 10 Apr 2014 13:58:40 -0400 Luiz Capitulino
> wrote:
>
> > The HugeTLB subsystem uses the buddy allocator to allocate hugepages during
> > runtime. This means that hugepages allocation during runtime is lim
On Thu, 17 Apr 2014 16:00:39 -0700
Andrew Morton wrote:
> On Thu, 10 Apr 2014 13:58:45 -0400 Luiz Capitulino
> wrote:
>
> > HugeTLB is limited to allocating hugepages whose size are less than
> > MAX_ORDER order. This is so because HugeTLB allocates hugepages via
&g
On Thu, 17 Apr 2014 16:00:39 -0700
Andrew Morton a...@linux-foundation.org wrote:
On Thu, 10 Apr 2014 13:58:45 -0400 Luiz Capitulino lcapitul...@redhat.com
wrote:
HugeTLB is limited to allocating hugepages whose size are less than
MAX_ORDER order. This is so because HugeTLB allocates
On Thu, 17 Apr 2014 16:01:10 -0700
Andrew Morton a...@linux-foundation.org wrote:
On Thu, 10 Apr 2014 13:58:40 -0400 Luiz Capitulino lcapitul...@redhat.com
wrote:
The HugeTLB subsystem uses the buddy allocator to allocate hugepages during
runtime. This means that hugepages allocation
On Thu, 17 Apr 2014 11:52:42 -0700
Andrew Morton wrote:
> On Thu, 17 Apr 2014 11:13:05 -0400 Luiz Capitulino
> wrote:
>
> > On Thu, 10 Apr 2014 13:58:40 -0400
> > Luiz Capitulino wrote:
> >
> > > [Full introduction right after t
On Thu, 10 Apr 2014 13:58:40 -0400
Luiz Capitulino wrote:
> [Full introduction right after the changelog]
>
> Changelog
> -
>
> v3
>
> - Dropped unnecessary WARN_ON() call [Kirill]
> - Always check if the pfn range lies within a zone [Yasuaki]
> - R
On Thu, 10 Apr 2014 13:58:40 -0400
Luiz Capitulino lcapitul...@redhat.com wrote:
[Full introduction right after the changelog]
Changelog
-
v3
- Dropped unnecessary WARN_ON() call [Kirill]
- Always check if the pfn range lies within a zone [Yasuaki]
- Renamed some function
On Thu, 17 Apr 2014 11:52:42 -0700
Andrew Morton a...@linux-foundation.org wrote:
On Thu, 17 Apr 2014 11:13:05 -0400 Luiz Capitulino lcapitul...@redhat.com
wrote:
On Thu, 10 Apr 2014 13:58:40 -0400
Luiz Capitulino lcapitul...@redhat.com wrote:
[Full introduction right after
This function is going to be used by non-init code in a future
commit.
Signed-off-by: Luiz Capitulino
---
mm/hugetlb.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index dd30f22..957231b 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -690,8
Next commit will add new code which will want to call
for_each_node_mask_to_alloc() macro. Move it, its buddy
for_each_node_mask_to_free() and their dependencies up in the file so
the new code can use them. This is just code movement, no logic change.
Signed-off-by: Luiz Capitulino
Reviewed
untime
allocation support for gigantic pages was a better solution.
Luiz Capitulino (5):
hugetlb: prep_compound_gigantic_page(): drop __init marker
hugetlb: add hstate_is_gigantic()
hugetlb: update_and_free_page(): don't clear PG_reserved bit
hugetlb: move helpers up in the file
hugetl
he reason is that I don't
think it's reasonable to do the hard and long work required for
allocating a gigantic page at fault time. But it should be simple
to add this if wanted
Signed-off-by: Luiz Capitulino
---
mm/hugetlb.c | 167 +++---
Hugepages pages never get the PG_reserved bit set, so don't clear it.
However, note that if the bit gets mistakenly set free_pages_check() will
catch it.
Signed-off-by: Luiz Capitulino
---
mm/hugetlb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/hugetlb.c b/mm
Signed-off-by: Luiz Capitulino
Reviewed-by: Andrea Arcangeli
Reviewed-by: Naoya Horiguchi
Reviewed-by: Yasuaki Ishimatsu
---
include/linux/hugetlb.h | 5 +
mm/hugetlb.c| 28 ++--
2 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/include
Hugepages pages never get the PG_reserved bit set, so don't clear it.
However, note that if the bit gets mistakenly set free_pages_check() will
catch it.
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
mm/hugetlb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
Reviewed-by: Andrea Arcangeli aarca...@redhat.com
Reviewed-by: Naoya Horiguchi n-horigu...@ah.jp.nec.com
Reviewed-by: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
---
include/linux/hugetlb.h | 5 +
mm/hugetlb.c| 28
don't
think it's reasonable to do the hard and long work required for
allocating a gigantic page at fault time. But it should be simple
to add this if wanted
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
mm/hugetlb.c | 167
allocation support for gigantic pages was a better solution.
Luiz Capitulino (5):
hugetlb: prep_compound_gigantic_page(): drop __init marker
hugetlb: add hstate_is_gigantic()
hugetlb: update_and_free_page(): don't clear PG_reserved bit
hugetlb: move helpers up in the file
hugetlb: add
This function is going to be used by non-init code in a future
commit.
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
mm/hugetlb.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index dd30f22..957231b 100644
--- a/mm/hugetlb.c
+++ b
Next commit will add new code which will want to call
for_each_node_mask_to_alloc() macro. Move it, its buddy
for_each_node_mask_to_free() and their dependencies up in the file so
the new code can use them. This is just code movement, no logic change.
Signed-off-by: Luiz Capitulino lcapitul
On Wed, 9 Apr 2014 09:42:01 +0900
Yasuaki Ishimatsu wrote:
> (2014/04/09 4:02), Luiz Capitulino wrote:
> > HugeTLB is limited to allocating hugepages whose size are less than
> > MAX_ORDER order. This is so because HugeTLB allocates hugepages via
> > the buddy allo
On Wed, 9 Apr 2014 09:42:01 +0900
Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com wrote:
(2014/04/09 4:02), Luiz Capitulino wrote:
HugeTLB is limited to allocating hugepages whose size are less than
MAX_ORDER order. This is so because HugeTLB allocates hugepages via
the buddy allocator
On Tue, 8 Apr 2014 15:51:02 -0700
Andrew Morton wrote:
> On Mon, 7 Apr 2014 14:49:35 -0400 Luiz Capitulino
> wrote:
>
> > > > ---
> > > > arch/x86/include/asm/hugetlb.h | 10 +++
> > > > mm/hugetlb.c | 177
> > > > +
On Tue, 8 Apr 2014 23:51:26 +0300
"Kirill A. Shutemov" wrote:
> On Tue, Apr 08, 2014 at 03:02:18PM -0400, Luiz Capitulino wrote:
> > Hugepages pages never get the PG_reserved bit set, so don't clear it. But
> > add a warning just in case.
>
> I don't think W
On Tue, 08 Apr 2014 15:51:51 -0400
Naoya Horiguchi wrote:
> Hi Luiz,
>
> On Tue, Apr 08, 2014 at 03:02:16PM -0400, Luiz Capitulino wrote:
> > This function is going to be used by non-init code in a future
> > commit.
> >
> > Signed-off-by: Luiz Capituli
upport [Naoya]
- Added patch to drop __init from prep_compound_gigantic_page()
- Restricted the feature to x86_64 (more details in patch 5/5)
- Added reviewed-bys plus minor changelog changes
Luiz Capitulino (5):
hugetlb: prep_compound_gigantic_page(): drop __init marker
hugetlb: add hstate_is_gi
Signed-off-by: Luiz Capitulino
Reviewed-by: Andrea Arcangeli
Reviewed-by: Naoya Horiguchi
Reviewed-by: Yasuaki Ishimatsu
---
include/linux/hugetlb.h | 5 +
mm/hugetlb.c| 28 ++--
2 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/include
Next commit will add new code which will want to call
for_each_node_mask_to_alloc() macro. Move it, its buddy
for_each_node_mask_to_free() and their dependencies up in the file so
the new code can use them. This is just code movement, no logic change.
Signed-off-by: Luiz Capitulino
Reviewed
Hugepages pages never get the PG_reserved bit set, so don't clear it. But
add a warning just in case.
Signed-off-by: Luiz Capitulino
Reviewed-by: Andrea Arcangeli
Reviewed-by: Naoya Horiguchi
Reviewed-by: Yasuaki Ishimatsu
---
mm/hugetlb.c | 5 +++--
1 file changed, 3 insertions(+), 2
he reason is that I don't
think it's reasonable to do the hard and long work required for
allocating a gigantic page at fault time. But it should be simple
to add this if wanted
Signed-off-by: Luiz Capitulino
---
mm/hugetlb.c | 158 ++
This function is going to be used by non-init code in a future
commit.
Signed-off-by: Luiz Capitulino
---
mm/hugetlb.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 7c02b9d..319db28 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -689,8
This function is going to be used by non-init code in a future
commit.
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
mm/hugetlb.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 7c02b9d..319db28 100644
--- a/mm/hugetlb.c
+++ b
don't
think it's reasonable to do the hard and long work required for
allocating a gigantic page at fault time. But it should be simple
to add this if wanted
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
mm/hugetlb.c | 158
Hugepages pages never get the PG_reserved bit set, so don't clear it. But
add a warning just in case.
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
Reviewed-by: Andrea Arcangeli aarca...@redhat.com
Reviewed-by: Naoya Horiguchi n-horigu...@ah.jp.nec.com
Reviewed-by: Yasuaki Ishimatsu
Next commit will add new code which will want to call
for_each_node_mask_to_alloc() macro. Move it, its buddy
for_each_node_mask_to_free() and their dependencies up in the file so
the new code can use them. This is just code movement, no logic change.
Signed-off-by: Luiz Capitulino lcapitul
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
Reviewed-by: Andrea Arcangeli aarca...@redhat.com
Reviewed-by: Naoya Horiguchi n-horigu...@ah.jp.nec.com
Reviewed-by: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
---
include/linux/hugetlb.h | 5 +
mm/hugetlb.c| 28
[Naoya]
- Added patch to drop __init from prep_compound_gigantic_page()
- Restricted the feature to x86_64 (more details in patch 5/5)
- Added reviewed-bys plus minor changelog changes
Luiz Capitulino (5):
hugetlb: prep_compound_gigantic_page(): drop __init marker
hugetlb: add hstate_is_gigantic
On Tue, 08 Apr 2014 15:51:51 -0400
Naoya Horiguchi n-horigu...@ah.jp.nec.com wrote:
Hi Luiz,
On Tue, Apr 08, 2014 at 03:02:16PM -0400, Luiz Capitulino wrote:
This function is going to be used by non-init code in a future
commit.
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
On Tue, 8 Apr 2014 23:51:26 +0300
Kirill A. Shutemov kir...@shutemov.name wrote:
On Tue, Apr 08, 2014 at 03:02:18PM -0400, Luiz Capitulino wrote:
Hugepages pages never get the PG_reserved bit set, so don't clear it. But
add a warning just in case.
I don't think WARN_ON() is needed
On Tue, 8 Apr 2014 15:51:02 -0700
Andrew Morton a...@linux-foundation.org wrote:
On Mon, 7 Apr 2014 14:49:35 -0400 Luiz Capitulino lcapitul...@redhat.com
wrote:
---
arch/x86/include/asm/hugetlb.h | 10 +++
mm/hugetlb.c | 177
On Fri, 4 Apr 2014 12:05:17 +0900
Yasuaki Ishimatsu wrote:
> (2014/04/03 3:08), Luiz Capitulino wrote:
> > HugeTLB is limited to allocating hugepages whose size are less than
> > MAX_ORDER order. This is so because HugeTLB allocates hugepages via
> > the buddy allo
On Fri, 4 Apr 2014 12:05:17 +0900
Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com wrote:
(2014/04/03 3:08), Luiz Capitulino wrote:
HugeTLB is limited to allocating hugepages whose size are less than
MAX_ORDER order. This is so because HugeTLB allocates hugepages via
the buddy allocator
Hugepages pages never get the PG_reserved bit set, so don't clear it. But
add a warning just in case.
Signed-off-by: Luiz Capitulino
---
mm/hugetlb.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 8c50547..7e07e47 100644
--- a/mm
ussion of that series it was agreed that having runtime
allocation support for gigantic pages was a better solution.
Luiz Capitulino (4):
hugetlb: add hstate_is_gigantic()
hugetlb: update_and_free_page(): don't clear PG_reserved bit
hugetlb: move helpers up in the file
hugetlb: add s
Next commit will add new code which will want to call the
for_each_node_mask_to_alloc() macro. Move it, its buddy
for_each_node_mask_to_free() and their dependencies up in the file so
the new code can use them. This is just code movement, no logic change.
Signed-off-by: Luiz Capitulino
---
mm
Signed-off-by: Luiz Capitulino
---
include/linux/hugetlb.h | 5 +
mm/hugetlb.c| 28 ++--
2 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 8c43cc4..8590134 100644
--- a/include/linux
to add this if wanted
Signed-off-by: Luiz Capitulino
---
arch/x86/include/asm/hugetlb.h | 10 +++
mm/hugetlb.c | 177 ++---
2 files changed, 176 insertions(+), 11 deletions(-)
diff --git a/arch/x86/include/asm/hugetlb.h b/arch/x86/include/asm/hugetl
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
arch/x86/include/asm/hugetlb.h | 10 +++
mm/hugetlb.c | 177 ++---
2 files changed, 176 insertions(+), 11 deletions(-)
diff --git a/arch/x86/include/asm/hugetlb.h b/arch/x86/include
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
include/linux/hugetlb.h | 5 +
mm/hugetlb.c| 28 ++--
2 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 8c43cc4..8590134 100644
Next commit will add new code which will want to call the
for_each_node_mask_to_alloc() macro. Move it, its buddy
for_each_node_mask_to_free() and their dependencies up in the file so
the new code can use them. This is just code movement, no logic change.
Signed-off-by: Luiz Capitulino lcapitul
of that series it was agreed that having runtime
allocation support for gigantic pages was a better solution.
Luiz Capitulino (4):
hugetlb: add hstate_is_gigantic()
hugetlb: update_and_free_page(): don't clear PG_reserved bit
hugetlb: move helpers up in the file
hugetlb: add support
Hugepages pages never get the PG_reserved bit set, so don't clear it. But
add a warning just in case.
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
mm/hugetlb.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 8c50547..7e07e47
we don't allocate from
the buddy
Signed-off-by: Luiz Capitulino
---
This patch is a follow up for this series:
http://marc.info/?l=linux-mm=139234006724423=2
That series introduced a command-line option to allow the user to specify from
which NUMA node a 1GB hugepage allocation should be m
don't allocate from
the buddy
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
This patch is a follow up for this series:
http://marc.info/?l=linux-mmm=139234006724423w=2
That series introduced a command-line option to allow the user to specify from
which NUMA node a 1GB hugepage
On Thu, 20 Feb 2014 15:15:46 -0800 (PST)
David Rientjes wrote:
> Do I really need to do your work for you and work on 1GB hugepages at
> runtime, which many more people would be interested in? Or are we just
> seeking the easiest way out here with something that shuts the customer up
> and
On Wed, 19 Feb 2014 20:51:55 -0800 (PST)
David Rientjes wrote:
> On Wed, 19 Feb 2014, Luiz Capitulino wrote:
>
> > > Yes, my concrete objection is that the command line interface is
> > > unnecessary if you can dynamically allocate and free 1GB pages at runtime
> &
On Wed, 19 Feb 2014 20:51:55 -0800 (PST)
David Rientjes rient...@google.com wrote:
On Wed, 19 Feb 2014, Luiz Capitulino wrote:
Yes, my concrete objection is that the command line interface is
unnecessary if you can dynamically allocate and free 1GB pages at runtime
unless memory
On Thu, 20 Feb 2014 15:15:46 -0800 (PST)
David Rientjes rient...@google.com wrote:
Do I really need to do your work for you and work on 1GB hugepages at
runtime, which many more people would be interested in? Or are we just
seeking the easiest way out here with something that shuts the
On Wed, 19 Feb 2014 19:46:41 -0800 (PST)
David Rientjes wrote:
> On Wed, 19 Feb 2014, Marcelo Tosatti wrote:
>
> > We agree that, in the future, we'd like to provide the ability to
> > dynamically allocate and free 1GB pages at runtime.
> >
> > Extending the kernel command line interface is a
On Wed, 19 Feb 2014 19:46:41 -0800 (PST)
David Rientjes rient...@google.com wrote:
On Wed, 19 Feb 2014, Marcelo Tosatti wrote:
We agree that, in the future, we'd like to provide the ability to
dynamically allocate and free 1GB pages at runtime.
Extending the kernel command line
It should read "reclaimable slab" and not "reclaimable swap".
Signed-off-by: Luiz Capitulino
---
fs/proc/meminfo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/proc/meminfo.c b/fs/proc/meminfo.c
index 136e548..7445af0 100644
--- a/fs/proc/mem
It should read reclaimable slab and not reclaimable swap.
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
---
fs/proc/meminfo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/proc/meminfo.c b/fs/proc/meminfo.c
index 136e548..7445af0 100644
--- a/fs/proc/meminfo.c
301 - 400 of 588 matches
Mail list logo
