Jingbai Ma writes:
> On 03/11/2013 05:42 PM, Eric W. Biederman wrote:
>> The kernel is known bad. What is bad is unclear.
>> Executing any extra code is a bad idea.
>>
>> The history here is that before kexec-on-panic there were lots of dump
>> routines that did all of the crashdump logic in th
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
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 the memory pages scanning process
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 runni
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 of the first kernel into
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 (O
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, Jingbai Ma wrote:
...
>> Fi
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 running kernel's data structures.
> > So
Vivek Goyal writes:
> On Thu, Mar 07, 2013 at 01:54:45PM -0800, Eric W. Biederman wrote:
>> Vivek Goyal writes:
>> > I think this is not a good idea. It has several issues.
>>
>> Actually it does not appear to be doing any work in the first kernel.
>
> Looks like patch3 in series is doing that.
"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 of the first kernel into user space on the second
>>> kernel.
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 HP ProLiant DL980
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 of the first kernel into user space on the second
>> kernel. But the user space code has to re-implement
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 of the first kernel into user space on the second
> kernel. But the user space code has to re-implement some parts of the
> kernel memory management system
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):
From: Vivek Goyal
Subject: Re: [RFC PATCH 0/5] crash dump bitmap: scan memory pages in kernel to
speedup kernel dump process
Date: Thu, 7 Mar 2013 10:21:08 -0500
> On Thu, Mar 07, 2013 at 10:58:18PM +0800, Jingbai Ma wrote:
>>
>> 2. Scans all memory pages in makedumpfile
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 HP ProLiant DL980 G7 with 1TB RAM, makedumpfile
>> v1.5.3):
>>
>>
On Thu, Mar 7, 2013 at 7:21 AM, Vivek Goyal wrote:
> Looks like now hpa and yinghai have done the work to be able to load
> kdump kernel above 4GB. I am assuming this also removes the restriction
> that we can only reserve 512MB or 896MB in second kernel.
Yes, From v3.9 and kexec-tools 2.0.4 on x
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):
>
> Total scan Time
>
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):
Total scan Time
Original kernel
+ makedumpfile v1.5.3 cyclic mode 1958.05 s
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):
Total scan Time
Original kernel
+ makedumpfile v1.5.3 cyclic mode 1958.05 s
22 matches
Mail list logo
