lkml.org 
[lkml]   [2013]   [Mar]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC PATCH 0/5] crash dump bitmap: scan memory pages in kernel to speedup kernel dump process
    On 03/09/2013 12:13 AM, Eric W. Biederman wrote:
    > "Ma, Jingbai (Kingboard)"<kingboard.ma@hp.com> writes:
    >
    >> On 3/8/13 6:33 PM, "H. Peter Anvin"<hpa@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@hp.com)


    \
     
     \ /
      Last update: 2013-03-11 10:01    [W:4.127 / U:0.308 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site