[RFC] makedumpfile-1.5.1 RC

[Lisa Mitchell]

On Thu, 2012-12-13 at 05:06 +0000, Atsushi Kumagai wrote:

> 
> In cyclic mode, we can save only a chunk of bitmap at a time, 
> this fact forces us to scan each cyclic region twice as below:
> 
>   Step1: To determine the offset of kdump's page data region.
>   Step2: To distinguish whether each page is unnecessary or not.
> 
> Step1 should be done before writing phase (write_kdump_pages_and_bitmap_cyclic())
> and step2 is run while writing phase, the whole scan is needed for
> each step.
> On the other hand, v1.4 can execute both step1 and step2 with the temporary
> bitmap file, the whole scan is done just one time to create the file.
> 
> It's a disadvantage in performance, but I think it's unavoidable.
> (There is the exception when the number of cycles is 1, but current
> version also scan twice in spite of redundancy.)
> 
> If more performance is needed, I think we should invent other
> approaches like the idea discussed in the thread below:
> 
>   http://lists.infradead.org/pipermail/kexec/2012-December/007494.html
> 
> Besides, I think v1.4 with the local disc which can contain the temporary
> bitmap file is the fastest version for now.
> 
> > Atushi, am I using the new makedumpfile 1.5.1GA correctly with the
> > kernel patch? 
> 
> Yes, I think you can use mem_map array logic correctly with the patch.
> And you can confirm it with -D option. If you didn't meet the conditions
> to use mem_map array logic, the message below will be showed.
> 
>   "Can't select page_is_buddy handler; follow free lists instead of mem_map array."
> 
> > I didn't understand how to use the options of makedumpfile you
> > mentioned, and when I tried with a vmlinux file, and the -x option,
> > makedumpfile didn't even start, just failed and reset. 
> 
> It might be another problem related -x option.
> For investigation, could you run the command below and show its messages ?
> There is no need to run in 2nd kernel environment.
> 
>   # makedumpfile -g vmcoreinfo -x vmlinux
> 
> 
> Thanks
> Atsushi Kumagai
> 


Thanks for this info, Atsushi.

I was able to test makedumpfile-v1.5.1 on the 4 TB DL980 we had this
weekend, along with the kexec patch to invoke the memory array logic,
and I got encouraging results, in that the difference  in dump time
between makedumpfile 1.4  on a RHEL 6.3 system and makedumpfile-v1.5.1
with the memory array logic seems to be now very small:


Here are my results (file system timestamp data and note the system had
it's filesystem time set way in the past):

					

1.  makedumpfile 1.4 (RHEL 6.3 default), crashkernel 512M:

       root at spb crash]# ls -al --time-style=full-iso
127.0.0.1-2012-05-09-19:55:50^M
total 10757984^M
drwxr-xr-x. 2 root root        4096 2012-05-09 21:53:21.289507559
-0600 .^M
drwxr-xr-x. 4 root root        4096 2012-05-09 22:10:08.729553037
-0600 ..^M
-rw-------. 1 root root 11016160846 2012-05-09 21:53:21.020384817 -0600
vmcore^

21:53:21 - 19:55:50 

Dump filter/copy time:  1 hour, 57 minutes, 29 seconds


2. makedumpfile-v1.5.1, with kexec patch, using memory array logic, took
3 dumps to see variations in times:

ls -al --time-style=full-iso 127.0.0.1-2012-05-10-23:42:35^M
total 10444952^M
drwxr-xr-x. 2 root root        4096 2012-05-11 01:52:18.512639105
-0600 .^M
drwxr-xr-x. 6 root root        4096 2012-05-10 23:42:39.270955565
-0600 ..^M
-rw-------. 1 root root 10695618226 2012-05-11 01:52:18.479636812 -0600
vmcore^M

Dump filter/copy time: 2 hours, 9 minutes, 11 sec


127.0.0.1-2012-05-12-20:57:08:^M
total 10469304^M
drwxr-xr-x. 2 root root        4096 2012-05-12 23:05:39.082084132
-0600 .^M
drwxr-xr-x. 5 root root        4096 2012-05-12 20:57:12.627084279
-0600 ..^M
-rw-------. 1 root root 10720553208 2012-05-12 23:05:39.051082490 -0600
vmcore^M


Dump filter/copy time:  2 hours     8 minutes  26 seconds

27.0.0.1-2012-05-10-09:52:17:^M
total 10650776^M
drwxr-xr-x. 2 root root        4096 2012-05-10 12:04:22.456078284
-0600 .^M
drwxr-xr-x. 6 root root        4096 2012-05-10 09:52:22.068605263
-0600 ..^M
-rw-------. 1 root root 10906381384 2012-05-10 12:04:22.425076466 -0600
vmcore

Dump filter/copy time: 2 hours 13 minutes

So the dump times seem to vary + or minus 2-3 minutes, and the average
was about 2 hours 10 minutes, or 10-12 minutes longer than the
makedumpfile 1.4 dump time for a 4 TB system, when using a crashkernel
constrained to 384 MB, and the cyclic buffer feature is used.