[RFC PATCH 0/5] crash dump bitmap: scan memory pages in kernel to speedup kernel dump process

[Jingbai Ma]

On 03/09/2013 12:13 AM, Eric W. Biederman wrote:
> "Ma, Jingbai (Kingboard)"<kingboard.ma at hp.com>  writes:
>
>> On 3/8/13 6:33 PM, "H. Peter Anvin"<hpa at 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 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 again. And worse, it's architecture
>>>> dependent, more architectures supported, more codes have to be
>>>> implemented. All implementation in user space must be sync to kernel
>>>> implementation. It's may called "flexibility", but it's painful to
>>>> maintain the codes.
>>>>
>>>
>>> What?  You are basically talking about /dev/mem... there is nothing
>>> particularly magic about it at all.
>>
>> What we are talking about is filtering memory pages (AKA memory pages
>> classification)
>> The makedumpfile (or any other dumper in user space) has to know the
>> exactly
>> memory layout of the memory management data structures, it not only
>> architecture dependent, but also may varies in different kernel release.
>> At this point, /dev/mem doesn't give any help.
>> So IMHO, I would like to do it in kernel, rather than So keep tracking
>> changes in user space code.
>
> But the fact is there is no requirment that the crash dump capture
> kernel is the same version as the kernel that crashed.  In fact it has
> been common at some points in time to use slightly different build
> options, or slightly different kernels.  Say a 32bit PAE kernel to
> capture a 64bit x86_64 kernel.

The filtering code will be executed in the first kernel, so this problem 
will not be exist.

>
> So in fact performing this work in the kernel and is actively harmful to
> reliability and maintenance because it adds an incorrect assumption.
>
> If you do want the benefit of shared maintenance with the kernel one
> solution that has been suggested several times is to put code into
> tools/makedumpfile (probably a library) that encapsulates the kernel
> specific knowledge that can be loaded into the ramdisk when the
> crahsdump kernel is being loaded.
>
> That would allow shared maintenance along without breaking the
> possibility of supporting kernel versions.

Yes, you are right. But it requires makedumpfile changes significantly, 
and if we also want to shared the code with kernel memory management 
subsystem, I believe that's not a easy job. (at least to my limited 
kernel knowledge)

>
> Eric


-- 
Jingbai Ma (jingbai.ma at hp.com)