Hi Russell,
Could you please merge this to mainline? Thanks!
Jianguo Wu.
On 2014/4/24 10:51, Jianguo Wu wrote:
> On 2014/4/23 21:20, Will Deacon wrote:
>
>> Hi Jianguo,
>>
>> On Thu, Apr 17, 2014 at 10:43:01AM +0100, Marc Zyngier wrote:
>>> On Thu, Apr 17 20
Hi Russell,
Could you please merge this to mainline? Thanks!
Jianguo Wu.
On 2014/4/24 10:51, Jianguo Wu wrote:
On 2014/4/23 21:20, Will Deacon wrote:
Hi Jianguo,
On Thu, Apr 17, 2014 at 10:43:01AM +0100, Marc Zyngier wrote:
On Thu, Apr 17 2014 at 10:31:37 am BST, Jianguo Wu wujian
On 2014/4/23 21:20, Will Deacon wrote:
> Hi Jianguo,
>
> On Thu, Apr 17, 2014 at 10:43:01AM +0100, Marc Zyngier wrote:
>> On Thu, Apr 17 2014 at 10:31:37 am BST, Jianguo Wu
>> wrote:
>>> When enable LPAE and big-endian in a hisilicon board, while specify
>>
On 2014/4/23 21:20, Will Deacon wrote:
Hi Jianguo,
On Thu, Apr 17, 2014 at 10:43:01AM +0100, Marc Zyngier wrote:
On Thu, Apr 17 2014 at 10:31:37 am BST, Jianguo Wu wujian...@huawei.com
wrote:
When enable LPAE and big-endian in a hisilicon board, while specify
mem=384M mem=512M@7680M
tch fixes this issue much like it has been done already in the
cpu_v7_switch_mm case.
Signed-off-by: Jianguo Wu
Cc: sta...@vger.kernel.org
---
-v2: Refactoring code suggested by Ben Dooks.
-v3: Rewrite commit message suggested by Marc Zyngier.
---
arch/arm/mm/proc-v7-3level.S | 18 +++
.
Unfortunately, the current code always assumes the LE case,
leading to corruption of the PTE when clearing/setting bits.
This patch fixes this issue much like it has been done already in the
cpu_v7_switch_mm case.
Signed-off-by: Jianguo Wu wujian...@huawei.com
Cc: sta...@vger.kernel.org
---
-v2: Refactoring
On 2014/4/16 20:28, Marc Zyngier wrote:
> On 16/04/14 03:45, Jianguo Wu wrote:
>> On 2014/4/14 19:14, Marc Zyngier wrote:
>>
>>> On 14/04/14 11:43, Will Deacon wrote:
>>>> (catching up on old email)
>>>>
>>>> On Tue, Mar 18, 2014 at 07:
On 2014/4/16 20:28, Marc Zyngier wrote:
On 16/04/14 03:45, Jianguo Wu wrote:
On 2014/4/14 19:14, Marc Zyngier wrote:
On 14/04/14 11:43, Will Deacon wrote:
(catching up on old email)
On Tue, Mar 18, 2014 at 07:35:59AM +, Jianguo Wu wrote:
Cloud you please take a look
On 2014/4/14 19:14, Marc Zyngier wrote:
> On 14/04/14 11:43, Will Deacon wrote:
>> (catching up on old email)
>>
>> On Tue, Mar 18, 2014 at 07:35:59AM +, Jianguo Wu wrote:
>>> Cloud you please take a look at this?
>>
>> [...]
>>
>>> On
On 2014/4/14 19:14, Marc Zyngier wrote:
On 14/04/14 11:43, Will Deacon wrote:
(catching up on old email)
On Tue, Mar 18, 2014 at 07:35:59AM +, Jianguo Wu wrote:
Cloud you please take a look at this?
[...]
On 2014/2/17 15:05, Jianguo Wu wrote:
When enable LPAE and big-endian
On 2014/3/25 17:29, Andreas Sturmlechner wrote:
> Original Message from: Ben Hutchings
>>
>> One piece of my backport to 3.2.y went missing in the forward-port to
>> 3.4.y. Can you test 3.4.83 with this patch on top?
>>
>> Ben.
>
> iwlwifi works with the additional patch, thanks :)
>
>
>
On 2014/3/25 17:29, Andreas Sturmlechner wrote:
Original Message from: Ben Hutchings b...@decadent.org.uk
One piece of my backport to 3.2.y went missing in the forward-port to
3.4.y. Can you test 3.4.83 with this patch on top?
Ben.
iwlwifi works with the additional patch, thanks :)
Hi Russell,
Cloud you please take a look at this?
Thanks!
On 2014/2/17 15:05, Jianguo Wu wrote:
> When enable LPAE and big-endian in a hisilicon board, while specify
> mem=384M mem=512M@7680M, will get bad page state:
>
> Freeing unused kernel memory: 180K (c0466000 - c0493000
Hi Russell,
Cloud you please take a look at this?
Thanks!
On 2014/2/17 15:05, Jianguo Wu wrote:
When enable LPAE and big-endian in a hisilicon board, while specify
mem=384M mem=512M@7680M, will get bad page state:
Freeing unused kernel memory: 180K (c0466000 - c0493000)
BUG: Bad page
On 2014/3/6 10:52, David Rientjes wrote:
> On Wed, 5 Mar 2014, Andrew Morton wrote:
>
>>> This patchset introduces a standard interface through memcg that allows
>>> both of these conditions to be handled in the same clean way: users
>>> define memory.oom_reserve_in_bytes to define the reserve
On 2014/3/6 10:52, David Rientjes wrote:
On Wed, 5 Mar 2014, Andrew Morton wrote:
This patchset introduces a standard interface through memcg that allows
both of these conditions to be handled in the same clean way: users
define memory.oom_reserve_in_bytes to define the reserve and this
e-endian, will store low 32-bit in r2,
high 32-bit in r3; for big-endian, will store low 32-bit in r3,
high 32-bit in r2, this will cause wrong pfn stored in pte,
so we should exchange r2 and r3 for big-endian.
Signed-off-by: Jianguo Wu
---
arch/arm/mm/proc-v7-3level.S | 18 +-
exchange r2 and r3 for big-endian.
Signed-off-by: Jianguo Wu wujian...@huawei.com
---
arch/arm/mm/proc-v7-3level.S | 18 +-
1 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mm/proc-v7-3level.S b/arch/arm/mm/proc-v7-3level.S
index 01a719e..22e3ad6 100644
Ping...
On 2014/2/12 14:54, Jianguo Wu wrote:
> On 2014/2/11 18:40, Ben Dooks wrote:
>
>> On 11/02/14 09:20, Jianguo Wu wrote:
>>> When enable LPAE and big-endian in a hisilicon board, while specify
>>> mem=384M mem=512M@7680M, will get bad page state:
>>>
Ping...
On 2014/2/12 14:54, Jianguo Wu wrote:
On 2014/2/11 18:40, Ben Dooks wrote:
On 11/02/14 09:20, Jianguo Wu wrote:
When enable LPAE and big-endian in a hisilicon board, while specify
mem=384M mem=512M@7680M, will get bad page state:
Freeing unused kernel memory: 180K (c0466000
On 2014/2/11 18:40, Ben Dooks wrote:
> On 11/02/14 09:20, Jianguo Wu wrote:
>> When enable LPAE and big-endian in a hisilicon board, while specify
>> mem=384M mem=512M@7680M, will get bad page state:
>>
>> Freeing unused kernel memory: 180K (c0466000 - c0493000)
>&g
e-endian, will store low 32-bit in r2,
high 32-bit in r3; for big-endian, will store low 32-bit in r3,
high 32-bit in r2, this will cause wrong pfn stored in pte,
so we should exchange r2 and r3 for big-endian.
Signed-off-by: Jianguo Wu
---
arch/arm/mm/proc-v7-3level.S | 10 ++
1 files ch
exchange r2 and r3 for big-endian.
Signed-off-by: Jianguo Wu wujian...@huawei.com
---
arch/arm/mm/proc-v7-3level.S | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mm/proc-v7-3level.S b/arch/arm/mm/proc-v7-3level.S
index 6ba4bd9..71b3892 100644
--- a/arch/arm
On 2014/2/11 18:40, Ben Dooks wrote:
On 11/02/14 09:20, Jianguo Wu wrote:
When enable LPAE and big-endian in a hisilicon board, while specify
mem=384M mem=512M@7680M, will get bad page state:
Freeing unused kernel memory: 180K (c0466000 - c0493000)
BUG: Bad page state in process init
On 2014/1/22 4:41, David Rientjes wrote:
> On Tue, 21 Jan 2014, Jianguo Wu wrote:
>
>>> The problem is that slabinfo becomes excessively verbose and dumping it
>>> all to the kernel log often times causes important messages to be lost.
>>> This is why we cont
On 2014/1/22 4:41, David Rientjes wrote:
On Tue, 21 Jan 2014, Jianguo Wu wrote:
The problem is that slabinfo becomes excessively verbose and dumping it
all to the kernel log often times causes important messages to be lost.
This is why we control things like the tasklist dump with a VM
On 2014/1/21 13:34, David Rientjes wrote:
> On Mon, 20 Jan 2014, Jianguo Wu wrote:
>
>> When OOM happen, will dump buddy free areas info, hugetlb pages info,
>> memory state of all eligible tasks, per-cpu memory info.
>> But do not dump slab/vmalloc info, sometime, it's
On 2014/1/21 13:34, David Rientjes wrote:
On Mon, 20 Jan 2014, Jianguo Wu wrote:
When OOM happen, will dump buddy free areas info, hugetlb pages info,
memory state of all eligible tasks, per-cpu memory info.
But do not dump slab/vmalloc info, sometime, it's not enough to figure out
When OOM happen, will dump buddy free areas info, hugetlb pages info,
memory state of all eligible tasks, per-cpu memory info.
But do not dump slab/vmalloc info, sometime, it's not enough to figure out the
reason OOM happened.
So, my questions are:
1. Should dump slab/vmalloc info when OOM
When OOM happen, will dump buddy free areas info, hugetlb pages info,
memory state of all eligible tasks, per-cpu memory info.
But do not dump slab/vmalloc info, sometime, it's not enough to figure out the
reason OOM happened.
So, my questions are:
1. Should dump slab/vmalloc info when OOM
On 2014/1/17 20:04, Catalin Marinas wrote:
> On Fri, Jan 17, 2014 at 09:40:02AM +0000, Jianguo Wu wrote:
>> Now disabling kmemleak is an irreversible operation, but sometimes
>> we may need to re-enable kmemleak at runtime. So add a knob to enable
>> kmemleak at runtime:
>
On 2014/1/17 20:04, Catalin Marinas wrote:
On Fri, Jan 17, 2014 at 09:40:02AM +, Jianguo Wu wrote:
Now disabling kmemleak is an irreversible operation, but sometimes
we may need to re-enable kmemleak at runtime. So add a knob to enable
kmemleak at runtime:
echo on /sys/kernel/debug
Now disabling kmemleak is an irreversible operation, but sometimes
we may need to re-enable kmemleak at runtime. So add a knob to enable
kmemleak at runtime:
echo on > /sys/kernel/debug/kmemleak
Signed-off-by: Jianguo Wu
---
Documentation/kmemleak.txt |3 ++-
mm/kmemlea
Now disabling kmemleak is an irreversible operation, but sometimes
we may need to re-enable kmemleak at runtime. So add a knob to enable
kmemleak at runtime:
echo on /sys/kernel/debug/kmemleak
Signed-off-by: Jianguo Wu wujian...@huawei.com
---
Documentation/kmemleak.txt |3 ++-
mm
ns_info();
> + if (size)
> + count += __free_memory_core(start, start + size);
> +
Hi Philipp,
For some archs, like arm64, would use memblock.memory after system booting,
so we can not simply released to the buddy allocator, maybe need
!defined(CONFIG_ARCH_DISCA
to the buddy allocator, maybe need
!defined(CONFIG_ARCH_DISCARD_MEMBLOCK).
#ifdef CONFIG_HAVE_ARCH_PFN_VALID
int pfn_valid(unsigned long pfn)
{
return memblock_is_memory(pfn PAGE_SHIFT);
}
EXPORT_SYMBOL(pfn_valid);
Thanks,
Jianguo Wu
return count;
}
--
To unsubscribe from
Hi Kirill,
On 2013/12/16 22:25, Kirill A. Shutemov wrote:
> Jianguo Wu wrote:
>> In __page_check_address(), if address's pud is not present,
>> huge_pte_offset() will return NULL, we should check the return value.
>>
>> Signed-off-by: Jianguo Wu
>
> Looks
In __page_check_address(), if address's pud is not present,
huge_pte_offset() will return NULL, we should check the return value.
Signed-off-by: Jianguo Wu
---
mm/rmap.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/mm/rmap.c b/mm/rmap.c
index 55c8b8d..068522d
In __page_check_address(), if address's pud is not present,
huge_pte_offset() will return NULL, we should check the return value.
Signed-off-by: Jianguo Wu wujian...@huawei.com
---
mm/rmap.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/mm/rmap.c b/mm/rmap.c
index
Hi Kirill,
On 2013/12/16 22:25, Kirill A. Shutemov wrote:
Jianguo Wu wrote:
In __page_check_address(), if address's pud is not present,
huge_pte_offset() will return NULL, we should check the return value.
Signed-off-by: Jianguo Wu wujian...@huawei.com
Looks okay to me.
Acked
] SMP
So check PageHuge(page) after call migrate_pages() successfully.
Tested-by: Naoya Horiguchi
Cc: sta...@vger.kernel.org
Signed-off-by: Jianguo Wu
---
mm/memory-failure.c | 14 ++
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/mm/memory-failure.c b/mm/memory
Hi,
On 2013/12/13 10:32, Naoya Horiguchi wrote:
> On Fri, Dec 13, 2013 at 09:09:52AM +0800, Jianguo Wu wrote:
>> After a successful hugetlb page migration by soft offline, the source page
>> will either be freed into hugepage_freelists or buddy(over-commit page). If
>>
Horiguchi
Cc: sta...@vger.kernel.org
Signed-off-by: Jianguo Wu
---
mm/memory-failure.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index b7c1716..e5567f2 100644
--- a/mm/memory-failure.c
+++ b/mm/memory
.@vger.kernel.org"
> in patch description?
> And please fix a typo in subject line.
>
OK, thanks for your tested!
Thanks,
Jianguo Wu
> Thanks,
> Naoya Horiguchi
>
> On Thu, Dec 12, 2013 at 09:14:05PM +0800, Jianguo Wu wrote:
>> After a successful hugetlb page migra
-by: Jianguo Wu
---
mm/memory-failure.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index b7c1716..e5567f2 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1471,7 +1471,8 @@ static int get_any_page(struct
.
Signed-off-by: Jianguo Wu wujian...@huawei.com
---
mm/memory-failure.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index b7c1716..e5567f2 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1471,7
in patch description?
And please fix a typo in subject line.
OK, thanks for your tested!
Thanks,
Jianguo Wu
Thanks,
Naoya Horiguchi
On Thu, Dec 12, 2013 at 09:14:05PM +0800, Jianguo Wu wrote:
After a successful hugetlb page migration by soft offline, the source page
will either be freed
.
Tested-by: Naoya Horiguchi n-horigu...@ah.jp.nec.com
Cc: sta...@vger.kernel.org
Signed-off-by: Jianguo Wu wujian...@huawei.com
---
mm/memory-failure.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index b7c1716
Hi,
On 2013/12/13 10:32, Naoya Horiguchi wrote:
On Fri, Dec 13, 2013 at 09:09:52AM +0800, Jianguo Wu wrote:
After a successful hugetlb page migration by soft offline, the source page
will either be freed into hugepage_freelists or buddy(over-commit page). If
page is in
buddy, page_hstate
] Oops: [#1] SMP
So check PageHuge(page) after call migrate_pages() successfully.
Tested-by: Naoya Horiguchi n-horigu...@ah.jp.nec.com
Cc: sta...@vger.kernel.org
Signed-off-by: Jianguo Wu wujian...@huawei.com
---
mm/memory-failure.c | 14 ++
1 files changed, 10 insertions(+), 4
On 2013/12/5 22:39, Naoya Horiguchi wrote:
> On Thu, Dec 05, 2013 at 04:52:52PM +0800, Jianguo Wu wrote:
>> Two cleanups:
>> 1. remove redundant codes for hugetlb pages.
>> 2. end = pmd_addr_end(addr, end) restricts [addr, end) within PMD_SIZE,
>>this may increase
Two cleanups:
1. remove redundant codes for hugetlb pages.
2. end = pmd_addr_end(addr, end) restricts [addr, end) within PMD_SIZE,
this may increase do_mincore() calls, remove it.
Signed-off-by: Jianguo Wu
---
mm/mincore.c |7 ---
1 files changed, 0 insertions(+), 7 deletions
Two cleanups:
1. remove redundant codes for hugetlb pages.
2. end = pmd_addr_end(addr, end) restricts [addr, end) within PMD_SIZE,
this may increase do_mincore() calls, remove it.
Signed-off-by: Jianguo Wu wujian...@huawei.com
---
mm/mincore.c |7 ---
1 files changed, 0 insertions
On 2013/12/5 22:39, Naoya Horiguchi wrote:
On Thu, Dec 05, 2013 at 04:52:52PM +0800, Jianguo Wu wrote:
Two cleanups:
1. remove redundant codes for hugetlb pages.
2. end = pmd_addr_end(addr, end) restricts [addr, end) within PMD_SIZE,
this may increase do_mincore() calls, remove
Use more appropriate NUMA_NO_NODE instead of -1 in all archs' module_alloc()
Signed-off-by: Jianguo Wu
Acked-by: Ralf Baechle
---
arch/arm/kernel/module.c|2 +-
arch/arm64/kernel/module.c |2 +-
arch/mips/kernel/module.c |2 +-
arch/parisc/kernel/module.c |2 +-
arch
Use more appropriate NUMA_NO_NODE instead of -1 in all archs' module_alloc()
Signed-off-by: Jianguo Wu
Acked-by: Ralf Baechle
---
arch/arm/kernel/module.c|2 +-
arch/arm64/kernel/module.c |2 +-
arch/mips/kernel/module.c |2 +-
arch/parisc/kernel/module.c |2 +-
arch
Use more appropriate NUMA_NO_NODE instead of -1 in all archs' module_alloc()
Signed-off-by: Jianguo Wu wujian...@huawei.com
Acked-by: Ralf Baechle r...@linux-mips.org
---
arch/arm/kernel/module.c|2 +-
arch/arm64/kernel/module.c |2 +-
arch/mips/kernel/module.c |2 +-
arch
Use more appropriate NUMA_NO_NODE instead of -1 in all archs' module_alloc()
Signed-off-by: Jianguo Wu wujian...@huawei.com
Acked-by: Ralf Baechle r...@linux-mips.org
---
arch/arm/kernel/module.c|2 +-
arch/arm64/kernel/module.c |2 +-
arch/mips/kernel/module.c |2 +-
arch
On 2013/9/19 16:33, Petr Holasek wrote:
> On Mon, 16 Sep 2013, Jianguo Wu wrote:
>> In get_mergeable_page() local variable page is not initialized,
>> it may hold a garbage value, when find_mergeable_vma() return NULL,
>> get_mergeable_page() may return a garbage value to
On 2013/9/19 16:33, Petr Holasek wrote:
On Mon, 16 Sep 2013, Jianguo Wu wrote:
In get_mergeable_page() local variable page is not initialized,
it may hold a garbage value, when find_mergeable_vma() return NULL,
get_mergeable_page() may return a garbage value to the caller.
So initialize
Use more appropriate NUMA_NO_NODE instead of -1
Signed-off-by: Jianguo Wu
Acked-by: KOSAKI Motohiro
---
mm/mempolicy.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index 4baf12e..4f0cd20 100644
--- a/mm/mempolicy.c
+++ b/mm
On 2013/9/17 4:26, Cody P Schafer wrote:
>
>> @@ -1802,11 +1802,11 @@ static inline unsigned interleave_nid(struct
>> mempolicy *pol,
>>
>> /*
>>* Return the bit number of a random bit set in the nodemask.
>> - * (returns -1 if nodemask is empty)
>> + * (returns NUMA_NO_NOD if nodemask is
On 2013/9/17 0:19, KOSAKI Motohiro wrote:
> (9/16/13 8:53 AM), Jianguo Wu wrote:
>> Use more appropriate NUMA_NO_NODE instead of -1
>>
>> Signed-off-by: Jianguo Wu
>> ---
>> mm/mempolicy.c | 10 +-
>> 1 files changed, 5 insertions(+), 5 del
Use more appropriate NUMA_NO_NODE instead of -1
Signed-off-by: Jianguo Wu
---
mm/mempolicy.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index 4baf12e..4f73025 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -1083,7
In get_mergeable_page() local variable page is not initialized,
it may hold a garbage value, when find_mergeable_vma() return NULL,
get_mergeable_page() may return a garbage value to the caller.
So initialize page as NULL.
Signed-off-by: Jianguo Wu
---
mm/ksm.c |2 +-
1 files changed, 1
In get_mergeable_page() local variable page is not initialized,
it may hold a garbage value, when find_mergeable_vma() return NULL,
get_mergeable_page() may return a garbage value to the caller.
So initialize page as NULL.
Signed-off-by: Jianguo Wu wujian...@huawei.com
---
mm/ksm.c |2 +-
1
Use more appropriate NUMA_NO_NODE instead of -1
Signed-off-by: Jianguo Wu wujian...@huawei.com
---
mm/mempolicy.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index 4baf12e..4f73025 100644
--- a/mm/mempolicy.c
+++ b/mm
On 2013/9/17 0:19, KOSAKI Motohiro wrote:
(9/16/13 8:53 AM), Jianguo Wu wrote:
Use more appropriate NUMA_NO_NODE instead of -1
Signed-off-by: Jianguo Wu wujian...@huawei.com
---
mm/mempolicy.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
I think this patch
On 2013/9/17 4:26, Cody P Schafer wrote:
@@ -1802,11 +1802,11 @@ static inline unsigned interleave_nid(struct
mempolicy *pol,
/*
* Return the bit number of a random bit set in the nodemask.
- * (returns -1 if nodemask is empty)
+ * (returns NUMA_NO_NOD if nodemask is empty)
Use more appropriate NUMA_NO_NODE instead of -1
Signed-off-by: Jianguo Wu wujian...@huawei.com
Acked-by: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
---
mm/mempolicy.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index
Hi Tang,
On 2013/9/13 17:30, Tang Chen wrote:
> The Linux kernel cannot migrate pages used by the kernel. As a result, kernel
> pages cannot be hot-removed. So we cannot allocate hotpluggable memory for
> the kernel.
>
> ACPI SRAT (System Resource Affinity Table) contains the memory hotplug
Hi Tang,
On 2013/9/13 17:30, Tang Chen wrote:
The Linux kernel cannot migrate pages used by the kernel. As a result, kernel
pages cannot be hot-removed. So we cannot allocate hotpluggable memory for
the kernel.
ACPI SRAT (System Resource Affinity Table) contains the memory hotplug info.
Hi Wanpeng,
Thanks for your review, but this patch has minor format problem, please see
below.
Please review the resend one, thanks.
Thanks,
Jianguo Wu
On 2013/9/5 16:09, Wanpeng Li wrote:
> On Thu, Sep 05, 2013 at 03:57:47PM +0800, Jianguo Wu wrote:
>> Changelog:
>> *v1 -&g
hen TRANSPARENT_HUGEPAGE=y.
And since commit d39d33c332(thp: enable direct defrag), defrag is
enable for all transparent hugepage page faults by default, not only in
MADV_HUGEPAGE regions.
Signed-off-by: Jianguo Wu
---
mm/huge_memory.c | 11 ++-
1 files changed, 6 insertions(+), 5 deleti
hen TRANSPARENT_HUGEPAGE=y.
And since commit d39d33c332(thp: enable direct defrag), defrag is
enable for all transparent hugepage page faults by default, not only in
MADV_HUGEPAGE regions.
Signed-off-by: Jianguo Wu
---
mm/huge_memory.c | 12 ++--
1 files changed, 6 insertions(+), 6 deleti
On 2013/9/5 12:58, Wanpeng Li wrote:
> Hi Jianguo,
> On Thu, Sep 05, 2013 at 11:54:00AM +0800, Jianguo Wu wrote:
>> On 2013/9/5 11:37, Wanpeng Li wrote:
>>
>>> On Thu, Sep 05, 2013 at 11:04:22AM +0800, Jianguo Wu wrote:
>>>> Hi Wanpeng,
>>>>
>
On 2013/9/5 12:58, Wanpeng Li wrote:
Hi Jianguo,
On Thu, Sep 05, 2013 at 11:54:00AM +0800, Jianguo Wu wrote:
On 2013/9/5 11:37, Wanpeng Li wrote:
On Thu, Sep 05, 2013 at 11:04:22AM +0800, Jianguo Wu wrote:
Hi Wanpeng,
On 2013/9/5 10:11, Wanpeng Li wrote:
Hi Jianguo,
On Wed, Sep 04
TRANSPARENT_HUGEPAGE=y.
And since commit d39d33c332(thp: enable direct defrag), defrag is
enable for all transparent hugepage page faults by default, not only in
MADV_HUGEPAGE regions.
Signed-off-by: Jianguo Wu wujian...@huawei.com
---
mm/huge_memory.c | 12 ++--
1 files changed, 6 insertions
TRANSPARENT_HUGEPAGE=y.
And since commit d39d33c332(thp: enable direct defrag), defrag is
enable for all transparent hugepage page faults by default, not only in
MADV_HUGEPAGE regions.
Signed-off-by: Jianguo Wu wujian...@huawei.com
---
mm/huge_memory.c | 11 ++-
1 files changed, 6 insertions
Hi Wanpeng,
Thanks for your review, but this patch has minor format problem, please see
below.
Please review the resend one, thanks.
Thanks,
Jianguo Wu
On 2013/9/5 16:09, Wanpeng Li wrote:
On Thu, Sep 05, 2013 at 03:57:47PM +0800, Jianguo Wu wrote:
Changelog:
*v1 - v2: also update the stale
On 2013/9/5 11:37, Wanpeng Li wrote:
> On Thu, Sep 05, 2013 at 11:04:22AM +0800, Jianguo Wu wrote:
>> Hi Wanpeng,
>>
>> On 2013/9/5 10:11, Wanpeng Li wrote:
>>
>>> Hi Jianguo,
>>> On Wed, Sep 04, 2013 at 09:30:22PM +0800, Jianguo Wu wrote:
>>&
Hi Wanpeng,
On 2013/9/5 10:11, Wanpeng Li wrote:
> Hi Jianguo,
> On Wed, Sep 04, 2013 at 09:30:22PM +0800, Jianguo Wu wrote:
>> Since commit d39d33c332(thp: enable direct defrag), defrag is enable
>> for all transparent hugepage page faults by default, not only in
>&g
Since commit d39d33c332(thp: enable direct defrag), defrag is enable
for all transparent hugepage page faults by default, not only in
MADV_HUGEPAGE regions.
Signed-off-by: Jianguo Wu
---
mm/huge_memory.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/mm/huge_memory.c
Since commit d39d33c332(thp: enable direct defrag), defrag is enable
for all transparent hugepage page faults by default, not only in
MADV_HUGEPAGE regions.
Signed-off-by: Jianguo Wu wujian...@huawei.com
---
mm/huge_memory.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git
Hi Wanpeng,
On 2013/9/5 10:11, Wanpeng Li wrote:
Hi Jianguo,
On Wed, Sep 04, 2013 at 09:30:22PM +0800, Jianguo Wu wrote:
Since commit d39d33c332(thp: enable direct defrag), defrag is enable
for all transparent hugepage page faults by default, not only in
MADV_HUGEPAGE regions.
Signed-off
On 2013/9/5 11:37, Wanpeng Li wrote:
On Thu, Sep 05, 2013 at 11:04:22AM +0800, Jianguo Wu wrote:
Hi Wanpeng,
On 2013/9/5 10:11, Wanpeng Li wrote:
Hi Jianguo,
On Wed, Sep 04, 2013 at 09:30:22PM +0800, Jianguo Wu wrote:
Since commit d39d33c332(thp: enable direct defrag), defrag is enable
Cc linux...@kvack.org
On 2013/8/30 10:06, Jianguo Wu wrote:
> Use more appropriate NUMA_NO_NODE instead of -1 in some archs' module_alloc()
>
> Signed-off-by: Jianguo Wu
> ---
> arch/arm/kernel/module.c|2 +-
> arch/arm64/kernel/module.c |2 +-
> arch
On 2013/8/30 11:36, Jianguo Wu wrote:
> Since commit 8219fc48a(mm: node_states: introduce N_MEMORY),
> we introduced N_MEMORY, now N_MEMORY stands for the nodes that has any memory,
> and N_HIGH_MEMORY stands for the nodes that has normal or high memory.
>
> The code here
On 2013/8/30 16:49, Wanpeng Li wrote:
> On Fri, Aug 30, 2013 at 04:42:49PM +0800, Jianguo Wu wrote:
>> Use get_vm_area_size() to get vmalloc area's actual size without guard page.
>>
>
> Do you see this?
>
> http://marc.info/?l=linux-mm=137698172417316=2
>
Hi
Use get_vm_area_size() to get vmalloc area's actual size without guard page.
Signed-off-by: Jianguo Wu
---
mm/vmalloc.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 13a5495..abe13bc 100644
--- a/mm/vmalloc.c
+++ b/mm
On 2013/8/30 15:41, Michal Hocko wrote:
> On Fri 30-08-13 11:44:57, Jianguo Wu wrote:
>> Since commit 8219fc48a(mm: node_states: introduce N_MEMORY),
>
> But this very same commit also says:
> "
> A.example 2) mm/page_cgroup.c use N_HIGH_MEMORY t
On 2013/8/30 15:41, Michal Hocko wrote:
On Fri 30-08-13 11:44:57, Jianguo Wu wrote:
Since commit 8219fc48a(mm: node_states: introduce N_MEMORY),
But this very same commit also says:
A.example 2) mm/page_cgroup.c use N_HIGH_MEMORY twice:
One is in page_cgroup_init(void
Use get_vm_area_size() to get vmalloc area's actual size without guard page.
Signed-off-by: Jianguo Wu wujian...@huawei.com
---
mm/vmalloc.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 13a5495..abe13bc 100644
--- a/mm
On 2013/8/30 16:49, Wanpeng Li wrote:
On Fri, Aug 30, 2013 at 04:42:49PM +0800, Jianguo Wu wrote:
Use get_vm_area_size() to get vmalloc area's actual size without guard page.
Do you see this?
http://marc.info/?l=linux-mmm=137698172417316w=2
Hi Wanpeng,
Sorry for not notice your post
On 2013/8/30 11:36, Jianguo Wu wrote:
Since commit 8219fc48a(mm: node_states: introduce N_MEMORY),
we introduced N_MEMORY, now N_MEMORY stands for the nodes that has any memory,
and N_HIGH_MEMORY stands for the nodes that has normal or high memory.
The code here need to handle
Cc linux...@kvack.org
On 2013/8/30 10:06, Jianguo Wu wrote:
Use more appropriate NUMA_NO_NODE instead of -1 in some archs' module_alloc()
Signed-off-by: Jianguo Wu wujian...@huawei.com
---
arch/arm/kernel/module.c|2 +-
arch/arm64/kernel/module.c |2 +-
arch/mips/kernel
On 2013/8/30 11:44, Jianguo Wu wrote:
> Since commit 8219fc48a(mm: node_states: introduce N_MEMORY),
> we introduced N_MEMORY, now N_MEMORY stands for the nodes that has any memory,
> and N_HIGH_MEMORY stands for the nodes that has normal or high memory.
>
> The code here
Since commit 8219fc48a(mm: node_states: introduce N_MEMORY),
we introduced N_MEMORY, now N_MEMORY stands for the nodes that has any memory,
and N_HIGH_MEMORY stands for the nodes that has normal or high memory.
The code here need to handle with the nodes which have memory,
we should use N_MEMORY
instead.
Signed-off-by: Jianguo Wu
---
arch/ia64/kernel/uncached.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/ia64/kernel/uncached.c b/arch/ia64/kernel/uncached.c
index a96bcf8..d2e5545 100644
--- a/arch/ia64/kernel/uncached.c
+++ b/arch/ia64/kernel/uncached.c
instead.
Signed-off-by: Jianguo Wu
---
mm/sparse-vmemmap.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c
index 27eeab3..ca8f46b 100644
--- a/mm/sparse-vmemmap.c
+++ b/mm/sparse-vmemmap.c
@@ -52,7 +52,7 @@ void * __meminit
1 - 100 of 212 matches
Mail list logo
