CC'ing netdev@ to make more relative people know it.
On 11/12/2013 11:16 AM, Zhouping Liu wrote:
Hi All,
I found the WARNING in the latest mainline with commint 8b5baa460b.
[61323.305424] [ cut here ]
[61323.310562] WARNING: CPU: 8 PID: 12860 at net/core/sock.c:313
Hi All,
I found the WARNING in the latest mainline with commint 8b5baa460b.
[61323.305424] [ cut here ]
[61323.310562] WARNING: CPU: 8 PID: 12860 at net/core/sock.c:313
sk_clear_memalloc+0x49/0x70()
[61323.319779] Modules linked in: rpcsec_gss_krb5 nfsv4 dns_resolver nfs
Hi All,
I found the WARNING in the latest mainline with commint 8b5baa460b.
[61323.305424] [ cut here ]
[61323.310562] WARNING: CPU: 8 PID: 12860 at net/core/sock.c:313
sk_clear_memalloc+0x49/0x70()
[61323.319779] Modules linked in: rpcsec_gss_krb5 nfsv4 dns_resolver nfs
CC'ing netdev@ to make more relative people know it.
On 11/12/2013 11:16 AM, Zhouping Liu wrote:
Hi All,
I found the WARNING in the latest mainline with commint 8b5baa460b.
[61323.305424] [ cut here ]
[61323.310562] WARNING: CPU: 8 PID: 12860 at net/core/sock.c:313
Hello All,
I hit the following errors when running memcg_stress_test.sh comes from LTP
test suite on v3.11-rc7+:
snip -
[ 2163.674483] BUG: soft lockup - CPU#25 stuck for 23s! [memcg_process_s:5859]
[ 2163.674489] Modules linked in:
Hello All,
I hit the following errors when running memcg_stress_test.sh comes from LTP
test suite on v3.11-rc7+:
snip -
[ 2163.674483] BUG: soft lockup - CPU#25 stuck for 23s! [memcg_process_s:5859]
[ 2163.674489] Modules linked in:
On 07/25/2013 05:21 PM, Heiko Carstens wrote:
On Wed, Jul 24, 2013 at 10:09:13PM -0400, Zhouping Liu wrote:
Hello All,
I met the below error on b3a3a9c441 with s390x arch:
arch/s390/built-in.o: In function `sys_call_table_emu':
(.rodata+0x2b98): undefined reference to `sie_exit'
arch/s390
On 07/25/2013 05:21 PM, Heiko Carstens wrote:
On Wed, Jul 24, 2013 at 10:09:13PM -0400, Zhouping Liu wrote:
Hello All,
I met the below error on b3a3a9c441 with s390x arch:
arch/s390/built-in.o: In function `sys_call_table_emu':
(.rodata+0x2b98): undefined reference to `sie_exit'
arch/s390
Hello All,
I met the below error on b3a3a9c441 with s390x arch:
# make
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
CALLscripts/checksyscalls.sh
CHK include/generated/compile.h
CHK include/generated/uapi/linux/version.h
LINK
Hello All,
I met the below error on b3a3a9c441 with s390x arch:
# make
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
CALLscripts/checksyscalls.sh
CHK include/generated/compile.h
CHK include/generated/uapi/linux/version.h
LINK
On 05/16/2013 02:10 AM, Pekka Enberg wrote:
On Wed, May 15, 2013 at 8:10 PM, Zhouping Liu wrote:
From: Zhouping Liu
commit 48356303ff(mm, slab: Rename __cache_alloc() -> slab_alloc())
forgot to update the comment 'kmem_cache_alloc' to 'slab_alloc_node'.
Signed-off-by: Zhouping Liu
---
From: Zhouping Liu
commit 48356303ff(mm, slab: Rename __cache_alloc() -> slab_alloc())
forgot to update the comment 'kmem_cache_alloc' to 'slab_alloc_node'.
Signed-off-by: Zhouping Liu
---
mm/slab.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/slab.c b/mm/sla
From: Zhouping Liu z...@redhat.com
commit 48356303ff(mm, slab: Rename __cache_alloc() - slab_alloc())
forgot to update the comment 'kmem_cache_alloc' to 'slab_alloc_node'.
Signed-off-by: Zhouping Liu z...@redhat.com
---
mm/slab.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On 05/16/2013 02:10 AM, Pekka Enberg wrote:
On Wed, May 15, 2013 at 8:10 PM, Zhouping Liu sanweiday...@gmail.com wrote:
From: Zhouping Liu z...@redhat.com
commit 48356303ff(mm, slab: Rename __cache_alloc() - slab_alloc())
forgot to update the comment 'kmem_cache_alloc' to 'slab_alloc_node
- Original Message -
> From: CAI Qian
> Date: 2013/5/6
> Subject: 3.9.0: panic during boot at tick_do_broadcast
> To: LKML vger.kernel.org>
I bisected it, and found the murderer was this commit:
b352bc1cbc29 tick: Convert broadcast cpu bitmaps to cpumask_var_t
(CC'ed the patches'
- Original Message -
From: CAI Qian caiq...@redhat.com
Date: 2013/5/6
Subject: 3.9.0: panic during boot at tick_do_broadcast
To: LKML vger.kernel.org
I bisected it, and found the murderer was this commit:
b352bc1cbc29 tick: Convert broadcast cpu bitmaps to cpumask_var_t
(CC'ed the
Hello Heiko,
- Original Message -
> From: "Heiko Carstens"
> To: "Zhouping Liu"
> Cc: linux...@kvack.org, "LKML" , "caiqian"
> , "Caspar Zhang"
> , "Martin Schwidefsky"
> Sent: Tuesday, April 16, 2013 3:50:
Hello Heiko,
- Original Message -
From: Heiko Carstens heiko.carst...@de.ibm.com
To: Zhouping Liu z...@redhat.com
Cc: linux...@kvack.org, LKML linux-kernel@vger.kernel.org, caiqian
caiq...@redhat.com, Caspar Zhang
czh...@redhat.com, Martin Schwidefsky schwidef...@de.ibm.com
Sent
On 04/15/2013 01:56 PM, Heiko Carstens wrote:
On Sun, Apr 14, 2013 at 11:28:40PM -0400, Zhouping Liu wrote:
Hi All,
I hit the below crashed when doing memory related tests[1] on s390x:
--- snip -
� 15929.351639¨ � <0021c0a6>¨ shrink_inactive_list
On 04/15/2013 01:56 PM, Heiko Carstens wrote:
On Sun, Apr 14, 2013 at 11:28:40PM -0400, Zhouping Liu wrote:
Hi All,
I hit the below crashed when doing memory related tests[1] on s390x:
--- snip -
� 15929.351639¨ � 0021c0a6¨ shrink_inactive_list+0x1c6
Hi All,
I hit the below crashed when doing memory related tests[1] on s390x:
--- snip -
� 15929.351639¨ � <0021c0a6>¨ shrink_inactive_list+0x1c6/0x56c
� 15929.351647¨ � <0021c69e>¨ shrink_lruvec+0x252/0x56c
� 15929.351654¨ �
Hi All,
I hit the below crashed when doing memory related tests[1] on s390x:
--- snip -
� 15929.351639¨ � 0021c0a6¨ shrink_inactive_list+0x1c6/0x56c
� 15929.351647¨ � 0021c69e¨ shrink_lruvec+0x252/0x56c
� 15929.351654¨ � 0021ca44¨
On 04/07/2013 03:10 PM, Wanpeng Li wrote:
On Sun, Apr 07, 2013 at 02:29:30AM -0400, Zhouping Liu wrote:
Hello All,
When I did some testing to check thp's performance, the following
strange action occurred:
when a process try to allocate 500+(or other large value)
anonymous hugepage
Hello All,
When I did some testing to check thp's performance, the following
strange action occurred:
when a process try to allocate 500+(or other large value)
anonymous hugepage, the 'khugepaged' thread will stop to
scan vma. the testing system has 2Gb RAM, and the thp
enabled value is
Hello All,
When I did some testing to check thp's performance, the following
strange action occurred:
when a process try to allocate 500+(or other large value)
anonymous hugepage, the 'khugepaged' thread will stop to
scan vma. the testing system has 2Gb RAM, and the thp
enabled value is
On 04/07/2013 03:10 PM, Wanpeng Li wrote:
On Sun, Apr 07, 2013 at 02:29:30AM -0400, Zhouping Liu wrote:
Hello All,
When I did some testing to check thp's performance, the following
strange action occurred:
when a process try to allocate 500+(or other large value)
anonymous hugepage
On 04/02/2013 11:40 AM, Lin Feng wrote:
Hi Zhouping,
On 04/02/2013 11:09 AM, Zhouping Liu wrote:
I don't understand clearly the last sentence 'you'll probably only get 100%
hugepages only 1/512th of the time.'
could you please explain more details about 'only 1/512th of the time'?
IIUC, thp
On 04/02/2013 06:23 AM, David Rientjes wrote:
On Mon, 1 Apr 2013, Zhouping Liu wrote:
Hi all,
I found THP can't correctly distinguish one anonymous hugepage map.
1. when /sys/kernel/mm/transparent_hugepage/enabled is 'always', the
amount of THP always is one less.
It's not a problem
Hi all,
I found THP can't correctly distinguish one anonymous hugepage map.
1. when /sys/kernel/mm/transparent_hugepage/enabled is 'always', the
amount of THP always is one less.
Testing code:
snip
unsigned long hugepagesize = (1UL << 21);
int main()
{
void *addr;
Hi all,
I found THP can't correctly distinguish one anonymous hugepage map.
1. when /sys/kernel/mm/transparent_hugepage/enabled is 'always', the
amount of THP always is one less.
Testing code:
snip
unsigned long hugepagesize = (1UL 21);
int main()
{
void *addr;
On 04/02/2013 06:23 AM, David Rientjes wrote:
On Mon, 1 Apr 2013, Zhouping Liu wrote:
Hi all,
I found THP can't correctly distinguish one anonymous hugepage map.
1. when /sys/kernel/mm/transparent_hugepage/enabled is 'always', the
amount of THP always is one less.
It's not a problem
On 04/02/2013 11:40 AM, Lin Feng wrote:
Hi Zhouping,
On 04/02/2013 11:09 AM, Zhouping Liu wrote:
I don't understand clearly the last sentence 'you'll probably only get 100%
hugepages only 1/512th of the time.'
could you please explain more details about 'only 1/512th of the time'?
IIUC, thp
Hello All,
I hit the following crash in mainline(9a9284153d9 Merge branch 'drm-fixes' of
git://people.freedesktop.org/~airlied/linux)
snip -
[ 1874.514412] BUG: soft lockup - CPU#7 stuck for 22s! [numad:564]
[ 1874.520320] Modules linked in: ebtable_nat bnep bluetooth
Hello All,
I hit the following crash in mainline(9a9284153d9 Merge branch 'drm-fixes' of
git://people.freedesktop.org/~airlied/linux)
snip -
[ 1874.514412] BUG: soft lockup - CPU#7 stuck for 22s! [numad:564]
[ 1874.520320] Modules linked in: ebtable_nat bnep bluetooth
On 01/21/2013 06:56 PM, Michal Hocko wrote:
On Mon 21-01-13 03:39:07, Zhouping Liu wrote:
- Original Message -
From: "Kamezawa Hiroyuki"
To: "Tejun Heo"
Cc: "David Rientjes" , "Michal Hocko" , "Zhouping
Liu" ,
linux...@kvack.org,
- Original Message -
> From: "Kamezawa Hiroyuki"
> To: "Tejun Heo"
> Cc: "David Rientjes" , "Michal Hocko" ,
> "Zhouping Liu" ,
> linux...@kvack.org, "Li Zefan" , "CAI Qian"
> , "LKM
- Original Message -
From: Kamezawa Hiroyuki kamezawa.hir...@jp.fujitsu.com
To: Tejun Heo t...@kernel.org
Cc: David Rientjes rient...@google.com, Michal Hocko mho...@suse.cz,
Zhouping Liu z...@redhat.com,
linux...@kvack.org, Li Zefan lize...@huawei.com, CAI Qian
caiq
On 01/21/2013 06:56 PM, Michal Hocko wrote:
On Mon 21-01-13 03:39:07, Zhouping Liu wrote:
- Original Message -
From: Kamezawa Hiroyuki kamezawa.hir...@jp.fujitsu.com
To: Tejun Heo t...@kernel.org
Cc: David Rientjes rient...@google.com, Michal Hocko mho...@suse.cz, Zhouping
Liu z
On 01/04/2013 10:08 PM, Mel Gorman wrote:
Zhouping, please test this patch.
Tested it, the issue is gone with following patch.
Tested-by: Zhouping Liu
Thanks,
Zhouping
Andrea and Hugh, any comments on whether this could be improved?
---8<---
mm: thp: Acquire the anon_vma rwsem for l
On 01/04/2013 01:57 AM, Mel Gorman wrote:
(Adding Michel and Rik to cc)
On Mon, Dec 24, 2012 at 11:38:51PM -0500, Zhouping Liu wrote:
Hello all,
I found the below kernel bug using latest mainline(637704cbc95),
my hardware has 2 numa nodes, and it's easy to reproduce the issue
using LTP test
On 01/04/2013 01:57 AM, Mel Gorman wrote:
(Adding Michel and Rik to cc)
On Mon, Dec 24, 2012 at 11:38:51PM -0500, Zhouping Liu wrote:
Hello all,
I found the below kernel bug using latest mainline(637704cbc95),
my hardware has 2 numa nodes, and it's easy to reproduce the issue
using LTP test
On 01/04/2013 10:08 PM, Mel Gorman wrote:
Zhouping, please test this patch.
Tested it, the issue is gone with following patch.
Tested-by: Zhouping Liu z...@redhat.com
Thanks,
Zhouping
Andrea and Hugh, any comments on whether this could be improved?
---8---
mm: thp: Acquire the anon_vma
On 12/28/2012 10:45 AM, Zhouping Liu wrote:
Thank you for the report Zhouping!
Would you be so kind to test the following patch and report results?
Apply the patch to the latest mainline.
Hello Zlatko,
I have tested the below patch(applied it on mainline directly),
but IMO, I'd like to say
On 12/28/2012 10:45 AM, Zhouping Liu wrote:
Thank you for the report Zhouping!
Would you be so kind to test the following patch and report results?
Apply the patch to the latest mainline.
Hello Zlatko,
I have tested the below patch(applied it on mainline directly),
but IMO, I'd like to say
On 12/28/2012 10:45 AM, Zhouping Liu wrote:
Thank you for the report Zhouping!
Would you be so kind to test the following patch and report results?
Apply the patch to the latest mainline.
Hello Zlatko,
I have tested the below patch(applied it on mainline directly),
but IMO, I'd like to say
>
> Thank you for the report Zhouping!
>
> Would you be so kind to test the following patch and report results?
> Apply the patch to the latest mainline.
Hello Zlatko,
I have tested the below patch(applied it on mainline directly),
but IMO, I'd like to say it maybe don't fix the issue
Thank you for the report Zhouping!
Would you be so kind to test the following patch and report results?
Apply the patch to the latest mainline.
Hello Zlatko,
I have tested the below patch(applied it on mainline directly),
but IMO, I'd like to say it maybe don't fix the issue completely.
On 12/28/2012 10:45 AM, Zhouping Liu wrote:
Thank you for the report Zhouping!
Would you be so kind to test the following patch and report results?
Apply the patch to the latest mainline.
Hello Zlatko,
I have tested the below patch(applied it on mainline directly),
but IMO, I'd like to say
On 12/26/2012 08:01 PM, Hillf Danton wrote:
On Wed, Dec 26, 2012 at 7:22 PM, Zhouping Liu wrote:
Hello everyone,
The latest mainline(637704cbc95c) would trigger the following error when the
system was under
some pressure condition(in my testing, I used oom01 case inside LTP test suite
On 12/26/2012 08:01 PM, Hillf Danton wrote:
On Wed, Dec 26, 2012 at 7:22 PM, Zhouping Liu z...@redhat.com wrote:
Hello everyone,
The latest mainline(637704cbc95c) would trigger the following error when the
system was under
some pressure condition(in my testing, I used oom01 case inside LTP
On 12/25/2012 08:05 PM, Hillf Danton wrote:
On Tue, Dec 25, 2012 at 12:38 PM, Zhouping Liu wrote:
Hello all,
I found the below kernel bug using latest mainline(637704cbc95),
my hardware has 2 numa nodes, and it's easy to reproduce the issue
using LTP test case: "# ./mmap10 -a -s -c 200&q
On 12/25/2012 08:05 PM, Hillf Danton wrote:
On Tue, Dec 25, 2012 at 12:38 PM, Zhouping Liu z...@redhat.com wrote:
Hello all,
I found the below kernel bug using latest mainline(637704cbc95),
my hardware has 2 numa nodes, and it's easy to reproduce the issue
using LTP test case: # ./mmap10 -a -s
Hello all,
I found the below kernel bug using latest mainline(637704cbc95),
my hardware has 2 numa nodes, and it's easy to reproduce the issue
using LTP test case: "# ./mmap10 -a -s -c 200":
[root@localhost linux]# cat .config | grep NUMA
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
Hello all,
I found the below kernel bug using latest mainline(637704cbc95),
my hardware has 2 numa nodes, and it's easy to reproduce the issue
using LTP test case: # ./mmap10 -a -s -c 200:
[root@localhost linux]# cat .config | grep NUMA
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
On 11/23/2012 06:53 AM, Ingo Molnar wrote:
* Ingo Molnar wrote:
This release mainly addresses one of the regressions Linus
(rightfully) complained about: the "4x JVM" SPECjbb run.
[ Note to testers: if possible please still run with
CONFIG_TRANSPARENT_HUGEPAGES=y enabled, to avoid the
On 11/23/2012 06:53 AM, Ingo Molnar wrote:
* Ingo Molnar mi...@kernel.org wrote:
This release mainly addresses one of the regressions Linus
(rightfully) complained about: the 4x JVM SPECjbb run.
[ Note to testers: if possible please still run with
CONFIG_TRANSPARENT_HUGEPAGES=y enabled,
cpu。
richard, I'm not sure whether your problem is occurred with the
patch-set or not,
if it's not related to the patches, you should report it on a *new* subject.
Thanks,
Zhouping
>
>
> want help me
>
> richard
>
>
>
On 11/07/2012 11:25 PM, Mel Gorman wrote:
On Wed, Nov 07, 2012 at 05:27:12PM +0800, Zhouping Liu wrote:
Hello Mel,
my 2 nodes machine hit a panic fault after applied the patch
set(based on kernel-3.7.0-rc4), please review it:
Early initialisation problem by the looks of things. Try
On 11/07/2012 11:25 PM, Mel Gorman wrote:
On Wed, Nov 07, 2012 at 05:27:12PM +0800, Zhouping Liu wrote:
Hello Mel,
my 2 nodes machine hit a panic fault after applied the patch
set(based on kernel-3.7.0-rc4), please review it:
SNIP
Early initialisation problem by the looks of things. Try
or not,
if it's not related to the patches, you should report it on a *new* subject.
Thanks,
Zhouping
want help me
richard
2012/11/8 Zhouping Liu z...@redhat.com
On 11/07/2012 11:25 PM, Mel Gorman wrote:
On Wed, Nov 07, 2012
On 11/01/2012 09:41 PM, Hugh Dickins wrote:
On Wed, 31 Oct 2012, Hugh Dickins wrote:
On Wed, 31 Oct 2012, Zhouping Liu wrote:
On 10/31/2012 03:26 PM, Hugh Dickins wrote:
There's quite a few put_page()s in do_huge_pmd_numa_page(), and it
would help if we could focus on the one which is giving
On 11/01/2012 09:41 PM, Hugh Dickins wrote:
On Wed, 31 Oct 2012, Hugh Dickins wrote:
On Wed, 31 Oct 2012, Zhouping Liu wrote:
On 10/31/2012 03:26 PM, Hugh Dickins wrote:
There's quite a few put_page()s in do_huge_pmd_numa_page(), and it
would help if we could focus on the one which is giving
On 10/31/2012 03:26 PM, Hugh Dickins wrote:
On Tue, 30 Oct 2012, Johannes Weiner wrote:
[88099.923724] [ cut here ]
[88099.924036] kernel BUG at mm/memcontrol.c:1134!
[88099.924036] invalid opcode: [#1] SMP
[88099.924036] Modules linked in: lockd sunrpc kvm_amd kvm
On 10/31/2012 03:26 PM, Hugh Dickins wrote:
On Tue, 30 Oct 2012, Johannes Weiner wrote:
[88099.923724] [ cut here ]
[88099.924036] kernel BUG at mm/memcontrol.c:1134!
[88099.924036] invalid opcode: [#1] SMP
[88099.924036] Modules linked in: lockd sunrpc kvm_amd kvm
On 10/29/2012 01:56 AM, Johannes Weiner wrote:
On Fri, Oct 26, 2012 at 11:08:00AM +0200, Peter Zijlstra wrote:
On Fri, 2012-10-26 at 17:07 +0800, Zhouping Liu wrote:
[ 180.918591] RIP: 0010:[] []
mem_cgroup_prepare_migration+0xba/0xd0
[ 182.681450] [] do_huge_pmd_numa_page+0x180/0x500
On 10/29/2012 01:56 AM, Johannes Weiner wrote:
On Fri, Oct 26, 2012 at 11:08:00AM +0200, Peter Zijlstra wrote:
On Fri, 2012-10-26 at 17:07 +0800, Zhouping Liu wrote:
[ 180.918591] RIP: 0010:[8118c39a] [8118c39a]
mem_cgroup_prepare_migration+0xba/0xd0
[ 182.681450
On 10/29/2012 04:24 PM, Johannes Weiner wrote:
Hello Ingo!
On Mon, Oct 29, 2012 at 07:50:44AM +0100, Ingo Molnar wrote:
* Zhouping Liu wrote:
Hi Johannes,
Tested the below patch, and I'm sure it has fixed the above
issue, thank you.
Thanks. Below is the folded up patch.
Ingo
On 10/29/2012 04:24 PM, Johannes Weiner wrote:
Hello Ingo!
On Mon, Oct 29, 2012 at 07:50:44AM +0100, Ingo Molnar wrote:
* Zhouping Liu z...@redhat.com wrote:
Hi Johannes,
Tested the below patch, and I'm sure it has fixed the above
issue, thank you.
Thanks. Below is the folded up patch
On 10/29/2012 01:56 AM, Johannes Weiner wrote:
On Fri, Oct 26, 2012 at 11:08:00AM +0200, Peter Zijlstra wrote:
On Fri, 2012-10-26 at 17:07 +0800, Zhouping Liu wrote:
[ 180.918591] RIP: 0010:[] []
mem_cgroup_prepare_migration+0xba/0xd0
[ 182.681450] [] do_huge_pmd_numa_page+0x180/0x500
On 10/29/2012 01:56 AM, Johannes Weiner wrote:
On Fri, Oct 26, 2012 at 11:08:00AM +0200, Peter Zijlstra wrote:
On Fri, 2012-10-26 at 17:07 +0800, Zhouping Liu wrote:
[ 180.918591] RIP: 0010:[8118c39a] [8118c39a]
mem_cgroup_prepare_migration+0xba/0xd0
[ 182.681450
On 10/26/2012 05:20 PM, Ingo Molnar wrote:
* Peter Zijlstra wrote:
On Fri, 2012-10-26 at 17:07 +0800, Zhouping Liu wrote:
[ 180.918591] RIP: 0010:[] []
mem_cgroup_prepare_migration+0xba/0xd0
[ 182.681450] [] do_huge_pmd_numa_page+0x180/0x500
[ 182.775090] [] handle_mm_fault+0x1e9
On 10/26/2012 05:20 PM, Ingo Molnar wrote:
* Peter Zijlstra wrote:
On Fri, 2012-10-26 at 17:07 +0800, Zhouping Liu wrote:
[ 180.918591] RIP: 0010:[] []
mem_cgroup_prepare_migration+0xba/0xd0
[ 182.681450] [] do_huge_pmd_numa_page+0x180/0x500
[ 182.775090] [] handle_mm_fault+0x1e9
On 10/26/2012 05:20 PM, Ingo Molnar wrote:
* Peter Zijlstra a.p.zijls...@chello.nl wrote:
On Fri, 2012-10-26 at 17:07 +0800, Zhouping Liu wrote:
[ 180.918591] RIP: 0010:[8118c39a] [8118c39a]
mem_cgroup_prepare_migration+0xba/0xd0
[ 182.681450] [81183b60
On 10/26/2012 05:20 PM, Ingo Molnar wrote:
* Peter Zijlstra a.p.zijls...@chello.nl wrote:
On Fri, 2012-10-26 at 17:07 +0800, Zhouping Liu wrote:
[ 180.918591] RIP: 0010:[8118c39a] [8118c39a]
mem_cgroup_prepare_migration+0xba/0xd0
[ 182.681450] [81183b60
commit f0f57b2b1(mm: move hugepage test examples to tools/testing/selftests/vm)
moved map_hugetlb.c, hugepage-shm.c and hugepage-mmap.c tests into
tools/testing/selftests/vm/ directory, but it didn't update hugetlbpage.txt
Signed-off-by: Zhouping Liu
---
Documentation/vm/hugetlbpage.txt | 10
commit f0f57b2b1(mm: move hugepage test examples to tools/testing/selftests/vm)
moved map_hugetlb.c, hugepage-shm.c and hugepage-mmap.c tests into
tools/testing/selftests/vm/ directory, but it didn't update hugetlbpage.txt
Signed-off-by: Zhouping Liu sanweiday...@gmail.com
---
Documentation/vm
76 matches
Mail list logo
