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. Thanks Vivek
