Hello Hatayama-san, > How about the patch adding compression/IO time report? > I intended it only for the presentation of this RFC. I think the above patch was posted only for this discussion, and I won't merge it into the makedumpfile. > I'll post the corresponding patch in crash's side after crash 6.0.2 is > released, waiting for new configuration editing feature as Dave has > explained. If the Crash supports LZO compression, I'll merge the feature into the makedumpfile. Thanks. KUMAGAI, Atsushi On Wed, 07 Dec 2011 10:03:42 +0900 ( ) HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com> wrote: > Hello Kumagai-san, > > Thanks for the evaluation. > > So I'll re-post the patch soon removing RFC prefix in header. But > there is a remaining fix for checking command-line parameters relevant > to addition of the 'l' option. > > How about the patch adding compression/IO time report? > I intended it only for the presentation of this RFC. > > I'll post the corresponding patch in crash's side after crash 6.0.2 is > released, waiting for new configuration editing feature as Dave has > explained. > > Thanks. > HATAYAMA, Daisuke > > From: Atsushi Kumagai <kumagai-atsushi at mxc.nes.nec.co.jp> > Subject: Re: [RFC] makedumpfile, crash: LZO compression support > Date: Mon, 5 Dec 2011 17:50:55 +0900 > > >> > Hello Hatayama-san, > >> > > >> > Thank you for your work. > >> > > >> >> Performance Comparison: > >> >> > >> >> Sample Data > >> >> > >> >> Ideally, I must have measured the performance for many enough > >> >> vmcores generated from machines that was actually running, but now > >> >> I don't have enough sample vmcores, I couldn't do so. So this > >> >> comparison doesn't answer question on I/O time improvement. This > >> >> is TODO for now. > >> > > >> > I'll measure the performance for actual vmcores by makedumpfile. > >> > Please wait for a while. > > > > I measured the performance of makedumpfile for some vmcores. > > Please see below. > > > > > > Sample Data > > > > To simulate a working server, I captured VMCOREs while almost all pages > > were alloceted and filled with random data. (See attached file "fill_random.c") > > > > I captured the VMCOREs of 5GB, 7.5GB and 10GB in the same condition. > > > > How to measure > > > > I measured the total execution time and the size of output file. > > > > $ time makedumpfile --message-level 16 [-c|-l| ] vmcore dumpfile > > > > Result > > > > See attached file "result.txt". > > > > > > This time, lzo's compression was the quickest, and lzo's compression ratio is > > almost the same(only a bit worse) as zlib's. > > It seems good, and I will merge the patch set into the makedumpfile. > > > > What is your opinion, Dave? > > > > > > Thanks. > > KUMAGAI, Atsushi > > > >> > >> That's very helpful. Thanks in advance. > >> > >> But of course I'm also still looking for alternative way. > >> > >> Thanks. > >> HATAYAMA, Daisuke > >>
