[RFC] makedumpfile-1.5.1 RC

Vivek Goyal vgoyal at redhat.com
Mon Nov 26 11:02:38 EST 2012

On Thu, Nov 22, 2012 at 12:49:35AM +0000, Hatayama, Daisuke wrote:
> > -----Original Message-----
> > From: kexec-bounces at lists.infradead.org
> > [mailto:kexec-bounces at lists.infradead.org] On Behalf Of Vivek Goyal
> > Sent: Wednesday, November 21, 2012 10:54 PM
> > To: Lisa Mitchell
> > Cc: kexec at lists.infradead.org; Atsushi Kumagai; Hoemann, Jerry; Cliff
> > Wickman
> > Subject: Re: [RFC] makedumpfile-1.5.1 RC
> [...]
> > > The changes proposed by Ciff Wickman in
> > > http://lists.infradead.org/pipermail/kexec/2012-November/007178.html
> > > sound like they could bring big improvements in performance, so these
> > > should be investigated.  I would like to try a version of them built on
> > > top of makedumpfile v1.5.1-rc, to try on our 4 TB system, to see what
> > > performance gains we can get, as an experiment.
> > 
> > I am wondering if it is time to look into parallel processing. Somebody
> > was working on bringing up more cpus in kdump kernel. If that works, the
> > probably multiple makedumpfile threads can try to filter out different
> > sections of physical memory.
> > 
> Makedumpfile has already had such parallel processing feature:
> $ ./makedumpfile --help
> ...
>   [--split]:
>       Split the dump data to multiple DUMPFILEs in parallel. If specifying
>       DUMPFILEs on different storage devices, a device can share I/O load with
>       other devices and it reduces time for saving the dump data. The file size
>       of each DUMPFILE is smaller than the system memory size which is divided
>       by the number of DUMPFILEs.
>       This feature supports only the kdump-compressed format.
> Doing makedumpfile like:
>   $ makedumpfile --split dumpfile vmcore1 vmcore2 [vmcore3 ... vmcore_n]

Ok, this is interesting. So reassembling of various vmcore fragments
happen later and user needs to explicitly do that?

> original dumpfile are splitted into n vmcores of kdump-compressed formats, each of
> which has the same size basically and where n processes are used, not threads.
> (The author told me the reason why process was chosen that he didn't want to put
> relatively large libc library in the 2nd kernel at that time. But recently, libc library is
> present on the 2nd kernel as scp needs to use it. This might no longer pointless.)
> I think Cliff's idea works orthogonally to parallel processing. I'll also test it on our
> machine.
> Also, sorry for delaying the work on multiple cpus in the 2nd kernel. Posting new
> version of the patch set is delayed a few weeks more. But it's possible to wake up
> AP cpus in the 2nd kernel safely if BIOS always assigns 0 lapicid to BSP since
> then if kexec enteres 2nd kernel with some AP lcpu, kernel always assigns 1 lcpu
> number to BSP lcpu. So, maxcpus=1 and waking up cpus except for 1 lcpu works
> as a workaround. If anyone wants to bench with parallel processing, please do it
> like this.

Thanks. If you happen to do some benchmarking, please do share the
numebrs. I am really curious to know if this parallel processing will
speed up the things enough to have reasonable dump times on multi tera
byte machines.


More information about the kexec mailing list