[RFC PATCH 0/4] makedumpfile: cyclic processing to keep memory consumption.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Atsushi,

do you have speed measurements for saving vmcore with this patches and
without them?
How much is speed up?

Thanks,
Maxim.

2012/5/31 Atsushi Kumagai <kumagai-atsushi at mxc.nes.nec.co.jp>

> Hello,
>
> I made the prototype of cyclic processing to keep memory consumption.
> I attache the patch set based on v1.4.4, I would like to get your advice.
>
> Introduction:
>
>  - The basic idea of cyclic processing is represented as below.
>  - cyclic processing doesn't use temporary bitmap file, store partial
> bitmap data
>   in memory only for each cycle instead.
>  - The prototype only support compressed kdump format.
>  - The prototype worked for almost kernel version except some kernel
> disabled PAE
>   in my environment.
>
> Basic idea (HATAYAMA-san wrote):
>
>   +------------------------------------------+
>   |    main header (struct disk_dump_header) |
>   |------------------------------------------+
>   |    sub header (struct kdump_sub_header)  |
>   |------------------------------------------+
>   |                                          | <-- 1st cycle
>   | -  -  -  -  -  -  -  -  -  -  -  -  -  - |
>   |            1st-bitmap                    | <-- 2nd cycle
>   | -  -  -  -  -  -  -  -  -  -  -  -  -  - |
>   |                                          | <-- 3rd cycle
>   |------------------------------------------+
>   |                                          | <-- 1st cycle
>   | -  -  -  -  -  -  -  -  -  -  -  -  -  - |
>   |            2nd-bitmap                    | <-- 2nd cycle
>   | -  -  -  -  -  -  -  -  -  -  -  -  -  - |
>   |                                          | <-- 3rd cycle
>   |------------------------------------------+
>   |                                          | <-- 1st cycle
>   | -  -  -  -  -  -  -  -  -  -  -  -  -  - |
>   |            page header                   | <-- 2nd cycle
>   | -  -  -  -  -  -  -  -  -  -  -  -  -  - |
>   |                                          | <-- 3rd cycle
>   |------------------------------------------|
>   |                                          |
>   |            page data                     | <-- 1st cycle
>   |                                          |
>   | -  -  -  -  -  -  -  -  -  -  -  -  -  - |
>   |            page data                     | <-- 2nd cycle
>   | -  -  -  -  -  -  -  -  -  -  -  -  -  - |
>   |                                          |
>   |                                          |
>   |            page data                     | <-- 3rd cycle
>   |                                          |
>   |                                          |
>   +------------------------------------------+
>
>
> How to use:
>
>  Specify 'K' option, then makedumpfile works cyclically.
>
> Example:
>
>  a. normal processing:
>
>    $ makedumpfile -cd31 vmcore testdump.cd31
>    Copying data                       : [100 %]
>
>    The dumpfile is saved to testdump.cd31.
>
>    makedumpfile Completed.
>
>  b. cyclic processing (too many messages will be displayed):
>
>    $ makedumpfile -Kcd31 vmcore testdump.Kcd31
>    Copying data                       : [  5 %]
>    Excluding free pages               : [100 %]
>    ...
>    Excluding free pages               : [100 %]
>    Copying data                       : [100 %]
>
>    The dumpfile is saved to testdump.Kcd31.
>
>    makedumpfile Completed.
>
>  c. compare each dumpfiles:
>
>    $ cmp testdump.cd31 testdump.Kcd31
>    $
>
> TODO:
>
>  - Optimize code for performance.
>   (e.g. initialize for compression is done every cycle, it's a waste.)
>  - Support ELF format.
>  - Consider suitable size of target region.
>  - Fix some messages.
>  - And something noticed by you.
>
>
> Thanks
> Atsushi Kumagai
>
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
>



-- 
Best regards,
Maxim Uvarov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/kexec/attachments/20120626/6c310d47/attachment.html>


[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux