lkml.org 
[lkml]   [2012]   [Apr]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH 0/2] kdump: Enter 2nd kernel with BSP for enabling multiple CPUs
    From
    From: "Eric W. Biederman" <ebiederm@xmission.com>
    Subject: Re: [PATCH 0/2] kdump: Enter 2nd kernel with BSP for enabling multiple CPUs
    Date: Sun, 15 Apr 2012 19:59:52 -0700

    > HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com> wrote:
    >
    >>Currently, booting up 2nd kernel with multiple CPUs fails in most
    >>cases since it enters 2nd kernel with AP if the crash happens on the
    >>AP. The problem is to signal startup IPI from AP to BSP.
    >
    > If so, then we need to fix our code that sends startupIPIs.
    > And perhaps the code that attempts to shutdown the other cpus.
    >

    Now maxcpus=1 is set at default, in which configuration, 2nd kernel
    doesn't try to wake up secondary and later CPUs. So there's no startup
    IPI on the 2nd kernel now.

    > It is not ok to switch cpus during kdump (reducing the reliability) just so you can write crash dumps faster. Better would be to cope with secondary cpus not booting.

    Even the current implememntation uses NMI to stop other CPUs. The
    reliability you are concerned about here is the possibility where the
    non-crashing BSP doesn't go into machine_kexec() due to some failures
    of interrupt processing, right?

    Alternative idea is:
    1) try to go into 2nd kernel with BSP,
    2) after some seconds, then try to go into 2nd kernel with crashing
    CPU. Then, think of CPUs except for the crashing cpu as abnormal,
    and use crashing cpu only on the 2nd kernel.

    This seems as reliable as the current one.

    >
    > I do like the direction of pounding on things so we can get multiple cpus going in large configurations. Although I am surprised you are cpu bound and not disk bound in the time to write your crash dumps.
    >

    What do you indicate in the 1st sentence? I don't understand around
    ``pounding on thing'', sorry.

    For the 2nd, it depends on data. If data is sparse enough, the data
    size is significantly reduced, and so IO size is also reduced. If data
    is randomized enough, compression takes much time and the data remains
    the same size, resulting in cpu bound processing.

    Thanks.
    HATAYAMA, Daisuke



    \
     
     \ /
      Last update: 2012-04-16 08:43    [W:6.199 / U:1.456 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site