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

[Jingbai Ma]

On 03/09/2013 12:13 AM, Eric W. Biederman wrote:
> "Ma, Jingbai (Kingboard)"<kingboard.ma@xxxxxx>  writes:
>
> > On 3/8/13 6:33 PM, "H. Peter Anvin"<hpa@xxxxxxxxx>  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@xxxxxx)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/