On 11/08/2013 01:21 PM, HATAYAMA Daisuke wrote:
> (2013/11/08 14:12), Atsushi Kumagai wrote:
>> Hello Jingbai,
>>
>> (2013/11/07 17:58), Jingbai Ma wrote:
>>> On 11/06/2013 10:23 PM, Vivek Goyal wrote:
>>>> On Wed, Nov 06, 2013 at 02:21:39AM +, Ats
On 11/06/2013 10:23 PM, Vivek Goyal wrote:
On Wed, Nov 06, 2013 at 02:21:39AM +, Atsushi Kumagai wrote:
(2013/11/06 5:27), Vivek Goyal wrote:
On Tue, Nov 05, 2013 at 09:45:32PM +0800, Jingbai Ma wrote:
This patch set intend to exclude unnecessary hugepages from vmcore dump file
On 11/06/2013 10:23 PM, Vivek Goyal wrote:
On Wed, Nov 06, 2013 at 02:21:39AM +, Atsushi Kumagai wrote:
(2013/11/06 5:27), Vivek Goyal wrote:
On Tue, Nov 05, 2013 at 09:45:32PM +0800, Jingbai Ma wrote:
This patch set intend to exclude unnecessary hugepages from vmcore dump file
On 11/08/2013 01:21 PM, HATAYAMA Daisuke wrote:
(2013/11/08 14:12), Atsushi Kumagai wrote:
Hello Jingbai,
(2013/11/07 17:58), Jingbai Ma wrote:
On 11/06/2013 10:23 PM, Vivek Goyal wrote:
On Wed, Nov 06, 2013 at 02:21:39AM +, Atsushi Kumagai wrote:
(2013/11/06 5:27), Vivek Goyal wrote
On 11/06/2013 04:26 AM, Vivek Goyal wrote:
On Tue, Nov 05, 2013 at 09:45:32PM +0800, Jingbai Ma wrote:
This patch set intend to exclude unnecessary hugepages from vmcore dump file.
This patch requires the kernel patch to export necessary data structures into
vmcore: "kexec: export hug
Add messages for print_info.
Signed-off-by: Jingbai Ma
---
print_info.c | 12 +++-
print_info.h |2 ++
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/print_info.c b/print_info.c
index 06939e0..978d9fb 100644
--- a/print_info.c
+++ b/print_info.c
@@ -103,17 +103,19
23 -d 127 /proc/vmcore /var/crash/kdump
To exclude all unnecessary pages but keep active hugepages:
makedumpfile -c --message-level 23 -d 63 /proc/vmcore /var/crash/kdump
---
Jingbai Ma (3):
makedumpfile: hugepage filtering: add hugepage filtering functions
makedumpfile: hugepage filt
Add new dump levels for makedumpfile manual page.
Signed-off-by: Jingbai Ma
---
makedumpfile.8 | 170
1 files changed, 133 insertions(+), 37 deletions(-)
diff --git a/makedumpfile.8 b/makedumpfile.8
index adeb811..70e8732 100644
Add functions to exclude hugepage from vmcore dump.
Signed-off-by: Jingbai Ma
---
makedumpfile.c | 272
makedumpfile.h | 19
2 files changed, 289 insertions(+), 2 deletions(-)
diff --git a/makedumpfile.c b/makedumpfile.c
index
s function, the hstates data structure has
to export into vmcoreinfo.
This patch based on Linux 3.12.
The patch set for makedumpfile to filter hugepage will be sent separately.
Signed-off-by: Jingbai Ma
---
kernel/kexec.c | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
, the hstates data structure has
to export into vmcoreinfo.
This patch based on Linux 3.12.
The patch set for makedumpfile to filter hugepage will be sent separately.
Signed-off-by: Jingbai Ma jingbai...@hp.com
---
kernel/kexec.c | 22 ++
1 files changed, 22 insertions(+), 0 deletions
Add new dump levels for makedumpfile manual page.
Signed-off-by: Jingbai Ma jingbai...@hp.com
---
makedumpfile.8 | 170
1 files changed, 133 insertions(+), 37 deletions(-)
diff --git a/makedumpfile.8 b/makedumpfile.8
index adeb811
Add functions to exclude hugepage from vmcore dump.
Signed-off-by: Jingbai Ma jingbai...@hp.com
---
makedumpfile.c | 272
makedumpfile.h | 19
2 files changed, 289 insertions(+), 2 deletions(-)
diff --git a/makedumpfile.c b
/vmcore /var/crash/kdump
To exclude all unnecessary pages but keep active hugepages:
makedumpfile -c --message-level 23 -d 63 /proc/vmcore /var/crash/kdump
---
Jingbai Ma (3):
makedumpfile: hugepage filtering: add hugepage filtering functions
makedumpfile: hugepage filtering: add
Add messages for print_info.
Signed-off-by: Jingbai Ma jingbai...@hp.com
---
print_info.c | 12 +++-
print_info.h |2 ++
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/print_info.c b/print_info.c
index 06939e0..978d9fb 100644
--- a/print_info.c
+++ b/print_info.c
On 11/06/2013 04:26 AM, Vivek Goyal wrote:
On Tue, Nov 05, 2013 at 09:45:32PM +0800, Jingbai Ma wrote:
This patch set intend to exclude unnecessary hugepages from vmcore dump file.
This patch requires the kernel patch to export necessary data structures into
vmcore: kexec: export hugepage data
On 08/13/2013 06:55 PM, Jingbai Ma wrote:
> On 08/06/2013 05:19 PM, HATAYAMA Daisuke wrote:
>> Hello,
>>
>> I've addressing kdump restriction that there's only one cpu available
>> on the kdump 2nd kernel. Now I need to check if the following CPU0 SMI
>> corrup
On 08/13/2013 06:55 PM, Jingbai Ma wrote:
On 08/06/2013 05:19 PM, HATAYAMA Daisuke wrote:
Hello,
I've addressing kdump restriction that there's only one cpu available
on the kdump 2nd kernel. Now I need to check if the following CPU0 SMI
corruption issue fixed in the following commit can
k everytime, sometimes I have to execute
insmod/rmmod several times to clear the BSP flag. (I used your
getcpuinfo.ko to check the BSP flag)
cpu: 0 bios_apic: 0 apic: 0 AP
cpu: 1 bios_apic: 1 apic: 1 AP
I suspended it, and them resumed it. This machine resumed from suspend
successfully, but the BSP flag has
suspend
successfully, but the BSP flag has been set back:
cpu: 0 bios_apic: 0 apic: 0 BSP
cpu: 1 bios_apic: 1 apic: 1 AP
That's all my observation. Hope it's helpful.
--
Thanks,
Jingbai Ma
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
)
Excluding pages Copy data Total
makedumpfile 1.5.3 468 1182 1650
makedumpfile 1.5.4 93 518611
So it seems there is a great performance improvement by the mmap mechanism.
--
Thanks,
Jingbai Ma
--
To unsubscribe from this list: send the line
)
Excluding pages Copy data Total
makedumpfile 1.5.3 468 1182 1650
makedumpfile 1.5.4 93 518611
So it seems there is a great performance improvement by the mmap mechanism.
--
Thanks,
Jingbai Ma
--
To unsubscribe from this list: send the line
| 23m40.010s| 18m19.932s| 21m47.903s| 22m47.605s|
-
|lzo non-cyclic | 20m45.749s| 16m42.045s| 15m41.070s| 15m18.605s|
-
--
Thanks,
Jingbai Ma
--
To unsubscribe from
| 23m40.010s| 18m19.932s| 21m47.903s| 22m47.605s|
-
|lzo non-cyclic | 20m45.749s| 16m42.045s| 15m41.070s| 15m18.605s|
-
--
Thanks,
Jingbai Ma
--
To unsubscribe from
On 03/27/2013 02:23 PM, HATAYAMA Daisuke wrote:
From: Jingbai Ma
Subject: makedumpfile mmap() benchmark
Date: Wed, 27 Mar 2013 13:51:37 +0800
Hi,
I have tested the makedumpfile mmap patch on a machine with 2TB
memory, here is testing results:
Thanks for your benchmark. It's very helpful
: 0x008544af
(The number of pages is reduced to 1%.)
Memory Hole : 0x1c0178b3
--
Total pages : 0x3c00
/Log
Thanks.
HATAYAMA, Daisuke
--
Thanks,
Jingbai Ma
--
To unsubscribe from this list: send the line
mmap 102483.66 477.23 560.89
1.5.3+mmap v3.9-rc3+mmap 204883.44 477.21 560.65
1.5.3+mmap v3.9-rc3+mmap 10240 83.84 476.56 560.4
Thanks,
Jingbai Ma
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
477.23 560.89
1.5.3+mmap v3.9-rc3+mmap 204883.44 477.21 560.65
1.5.3+mmap v3.9-rc3+mmap 10240 83.84 476.56 560.4
Thanks,
Jingbai Ma
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
On 03/11/2013 05:42 PM, Eric W. Biederman wrote:
Jingbai Ma writes:
On 03/08/2013 11:52 PM, Vivek Goyal wrote:
On Thu, Mar 07, 2013 at 01:54:45PM -0800, Eric W. Biederman wrote:
Vivek Goyal writes:
On Thu, Mar 07, 2013 at 10:58:18PM +0800, Jingbai Ma wrote:
This patch intend to speedup
On 03/11/2013 05:42 PM, Eric W. Biederman wrote:
Jingbai Majingbai...@hp.com writes:
On 03/08/2013 11:52 PM, Vivek Goyal wrote:
On Thu, Mar 07, 2013 at 01:54:45PM -0800, Eric W. Biederman wrote:
Vivek Goyalvgo...@redhat.com writes:
On Thu, Mar 07, 2013 at 10:58:18PM +0800, Jingbai Ma
On 03/09/2013 12:31 PM, HATAYAMA Daisuke wrote:
From: Jingbai Ma
Subject: Re: [RFC PATCH 0/5] crash dump bitmap: scan memory pages in kernel to
speedup kernel dump process
Date: Fri, 8 Mar 2013 18:06:31 +0800
On 03/07/2013 11:21 PM, Vivek Goyal wrote:
On Thu, Mar 07, 2013 at 10:58:18PM +0800
On 03/09/2013 12:19 AM, Vivek Goyal wrote:
On Fri, Mar 08, 2013 at 06:06:31PM +0800, Jingbai Ma wrote:
[..]
- First of all it is doing more stuff in first kernel. And that runs
contrary to kdump design where we want to do stuff in second kernel.
After a kernel crash, you can't trust
On 03/09/2013 12:13 AM, Eric W. Biederman wrote:
"Ma, Jingbai (Kingboard)" writes:
On 3/8/13 6:33 PM, "H. Peter Anvin" wrote:
On 03/08/2013 02:06 AM, Jingbai Ma wrote:
Kernel do have some abilities that user space haven't. It's possible to
map whole memory space
On 03/08/2013 11:52 PM, Vivek Goyal wrote:
On Thu, Mar 07, 2013 at 01:54:45PM -0800, Eric W. Biederman wrote:
Vivek Goyal writes:
On Thu, Mar 07, 2013 at 10:58:18PM +0800, Jingbai Ma wrote:
This patch intend to speedup the memory pages scanning process in
selective dump mode.
Test result
On 03/08/2013 11:52 PM, Vivek Goyal wrote:
On Thu, Mar 07, 2013 at 01:54:45PM -0800, Eric W. Biederman wrote:
Vivek Goyalvgo...@redhat.com writes:
On Thu, Mar 07, 2013 at 10:58:18PM +0800, Jingbai Ma wrote:
This patch intend to speedup the memory pages scanning process in
selective dump
On 03/09/2013 12:13 AM, Eric W. Biederman wrote:
Ma, Jingbai (Kingboard)kingboard...@hp.com writes:
On 3/8/13 6:33 PM, H. Peter Anvinh...@zytor.com wrote:
On 03/08/2013 02:06 AM, Jingbai Ma wrote:
Kernel do have some abilities that user space haven't. It's possible to
map whole memory
On 03/09/2013 12:19 AM, Vivek Goyal wrote:
On Fri, Mar 08, 2013 at 06:06:31PM +0800, Jingbai Ma wrote:
[..]
- First of all it is doing more stuff in first kernel. And that runs
contrary to kdump design where we want to do stuff in second kernel.
After a kernel crash, you can't trust
at 10:58:18PM +0800, Jingbai Ma wrote:
...
First of all 64MB per TB should not be a huge deal. And makedumpfile
also has this cyclic mode where you process a map, discard it and then
move on to next section. So memory usage remains constant at the
expense
of processing time.
Yes, that's true
On 03/07/2013 11:21 PM, Vivek Goyal wrote:
On Thu, Mar 07, 2013 at 10:58:18PM +0800, Jingbai Ma wrote:
This patch intend to speedup the memory pages scanning process in
selective dump mode.
Test result (On HP ProLiant DL980 G7 with 1TB RAM, makedumpfile
v1.5.3
On 03/07/2013 11:21 PM, Vivek Goyal wrote:
On Thu, Mar 07, 2013 at 10:58:18PM +0800, Jingbai Ma wrote:
This patch intend to speedup the memory pages scanning process in
selective dump mode.
Test result (On HP ProLiant DL980 G7 with 1TB RAM, makedumpfile
v1.5.3
On 03/07/2013 11:21 PM, Vivek Goyal wrote:
On Thu, Mar 07, 2013 at 10:58:18PM +0800, Jingbai Ma wrote:
This patch intend to speedup the memory pages scanning process in
selective dump mode.
Test result (On HP ProLiant DL980 G7 with 1TB RAM, makedumpfile
v1.5.3
On 03/07/2013 11:21 PM, Vivek Goyal wrote:
On Thu, Mar 07, 2013 at 10:58:18PM +0800, Jingbai Ma wrote:
This patch intend to speedup the memory pages scanning process in
selective dump mode.
Test result (On HP ProLiant DL980 G7 with 1TB RAM, makedumpfile
v1.5.3
Linux kernel 3.9-rc1 allows crashkernel above 4GB, but current
kexec-tools doesn't support it yet.
This patch is only a workaround to make kdump work again.
This patch should be removed after kexec-tools 2.0.4 release.
Signed-off-by: Jingbai Ma
---
arch/x86/kernel/setup.c |3 ++-
1 files
Add a procfs driver for selecting exclude pages in userspace.
/proc/crash_dump_bitmap/
Signed-off-by: Jingbai Ma
---
fs/proc/Makefile|1
fs/proc/crash_dump_bitmap.c | 221 +++
2 files changed, 222 insertions(+), 0 deletions(-)
create
Reserve a memory block for crash_dump_bitmap in kernel booting process.
Signed-off-by: Jingbai Ma
---
arch/x86/kernel/setup.c | 59 +
include/linux/crash_dump_bitmap.h | 59 +
kernel/Makefile
Add a kernel config and help document for CRASH_DUMP_BITMAP.
Signed-off-by: Jingbai Ma
---
Documentation/kdump/crash_dump_bitmap.txt | 378 +
arch/x86/Kconfig | 16 +
2 files changed, 394 insertions(+), 0 deletions(-)
create mode 100644
of existing memory pages scanning code in
userspace.
To do:
1. It only has been verified on x86 64bit platform, needs to be modified
for other platforms. (ARM, XEN, PPC, etc...)
---
Jingbai Ma (5):
crash dump bitmap: add a kernel config and help document
crash dump bitmap: init crash dump
Add a procfs driver for selecting exclude pages in userspace.
/proc/crash_dump_bitmap/
Signed-off-by: Jingbai Ma
---
fs/proc/Makefile|1
fs/proc/crash_dump_bitmap.c | 221 +++
2 files changed, 222 insertions(+), 0 deletions(-)
create
Linux kernel 3.9-rc1 allows crashkernel above 4GB, but current
kexec-tools doesn't support it yet.
This patch is only a workaround to make kdump work again.
This patch should be removed after kexec-tools 2.0.4 release.
Signed-off-by: Jingbai Ma
---
arch/x86/kernel/setup.c |3 ++-
1 files
In the kernel crash process, call generate_crash_dump_bitmap() to scans
all memory pages, clear the bit for all excluded memory pages in the
reserved memory.
Signed-off-by: Jingbai Ma
---
kernel/crash_dump_bitmap.c | 156
kernel/kexec.c
Reserve a memory block for crash_dump_bitmap in kernel booting process.
Signed-off-by: Jingbai Ma
---
arch/x86/kernel/setup.c | 59 +
include/linux/crash_dump_bitmap.h | 59 +
kernel/Makefile
Add a kernel config and help document for CRASH_DUMP_BITMAP.
Signed-off-by: Jingbai Ma
---
Documentation/kdump/crash_dump_bitmap.txt | 378 +
arch/x86/Kconfig | 16 +
2 files changed, 394 insertions(+), 0 deletions(-)
create mode 100644
of existing memory pages scanning code in
userspace.
To do:
1. It only has been verified on x86 64bit platform, needs to be modified
for other platforms. (ARM, XEN, PPC, etc...)
---
Jingbai Ma (5):
crash dump bitmap: add a kernel config and help document
crash dump bitmap: init crash dump
of existing memory pages scanning code in
userspace.
To do:
1. It only has been verified on x86 64bit platform, needs to be modified
for other platforms. (ARM, XEN, PPC, etc...)
---
Jingbai Ma (5):
crash dump bitmap: add a kernel config and help document
crash dump bitmap: init crash dump
Add a kernel config and help document for CRASH_DUMP_BITMAP.
Signed-off-by: Jingbai Ma jingbai...@hp.com
---
Documentation/kdump/crash_dump_bitmap.txt | 378 +
arch/x86/Kconfig | 16 +
2 files changed, 394 insertions(+), 0 deletions
Reserve a memory block for crash_dump_bitmap in kernel booting process.
Signed-off-by: Jingbai Ma jingbai...@hp.com
---
arch/x86/kernel/setup.c | 59 +
include/linux/crash_dump_bitmap.h | 59 +
kernel/Makefile
In the kernel crash process, call generate_crash_dump_bitmap() to scans
all memory pages, clear the bit for all excluded memory pages in the
reserved memory.
Signed-off-by: Jingbai Ma jingbai...@hp.com
---
kernel/crash_dump_bitmap.c | 156
kernel
Add a procfs driver for selecting exclude pages in userspace.
/proc/crash_dump_bitmap/
Signed-off-by: Jingbai Ma jingbai...@hp.com
---
fs/proc/Makefile|1
fs/proc/crash_dump_bitmap.c | 221 +++
2 files changed, 222 insertions(+), 0
Linux kernel 3.9-rc1 allows crashkernel above 4GB, but current
kexec-tools doesn't support it yet.
This patch is only a workaround to make kdump work again.
This patch should be removed after kexec-tools 2.0.4 release.
Signed-off-by: Jingbai Ma jingbai...@hp.com
---
arch/x86/kernel/setup.c
of existing memory pages scanning code in
userspace.
To do:
1. It only has been verified on x86 64bit platform, needs to be modified
for other platforms. (ARM, XEN, PPC, etc...)
---
Jingbai Ma (5):
crash dump bitmap: add a kernel config and help document
crash dump bitmap: init crash dump
Add a kernel config and help document for CRASH_DUMP_BITMAP.
Signed-off-by: Jingbai Ma jingbai...@hp.com
---
Documentation/kdump/crash_dump_bitmap.txt | 378 +
arch/x86/Kconfig | 16 +
2 files changed, 394 insertions(+), 0 deletions
Reserve a memory block for crash_dump_bitmap in kernel booting process.
Signed-off-by: Jingbai Ma jingbai...@hp.com
---
arch/x86/kernel/setup.c | 59 +
include/linux/crash_dump_bitmap.h | 59 +
kernel/Makefile
Add a procfs driver for selecting exclude pages in userspace.
/proc/crash_dump_bitmap/
Signed-off-by: Jingbai Ma jingbai...@hp.com
---
fs/proc/Makefile|1
fs/proc/crash_dump_bitmap.c | 221 +++
2 files changed, 222 insertions(+), 0
Linux kernel 3.9-rc1 allows crashkernel above 4GB, but current
kexec-tools doesn't support it yet.
This patch is only a workaround to make kdump work again.
This patch should be removed after kexec-tools 2.0.4 release.
Signed-off-by: Jingbai Ma jingbai...@hp.com
---
arch/x86/kernel/setup.c
64 matches
Mail list logo