makedumpfile memory usage grows with system memory size

[HATAYAMA Daisuke]

From: Don Zickus <dzickus at redhat.com>
Subject: Re: makedumpfile memory usage grows with system memory size
Date: Thu, 29 Mar 2012 09:25:33 -0400

> On Thu, Mar 29, 2012 at 09:56:46PM +0900, HATAYAMA Daisuke wrote:

>> From: "Ken'ichi Ohmichi" <oomichi at mxs.nes.nec.co.jp>
>> Subject: Re: makedumpfile memory usage grows with system memory size
>> Date: Thu, 29 Mar 2012 17:09:18 +0900

>> > On Wed, 28 Mar 2012 17:22:04 -0400
>> > Don Zickus <dzickus at redhat.com> wrote:

>> >> I was curious if that was true and if it was, would it be possible to only
>> >> process memory in chunks instead of all at once.
>> >> 
>> >> The idea is that a machine with 4Gigs of memory should consume the same
>> >> the amount of kdump runtime memory as a 1TB memory system.
>> >> 
>> >> Just trying to research ways to keep the memory requirements consistent
>> >> across all memory ranges.

>> I think this is possible in constant memory space by creating bitmaps
>> and writing pages in a certain amount of memory. That is, if choosing
>> 4GB, do [0, 4GB) space processing, [4GB, 8GB) space processing, [8GB,
>> 12GB) ... in order. The key is to restrict the target memory range of
>> filtering.

> Yes, that was what I was thinking.  I am glad to hear that is possible.
> Is there some place in the code that I can help try out that idea?  I
> would also be curious if there is a 'time' impact on how long it takes to
> process this (for example, would it add a couple of milliseconds overhead
> or seconds overhead).

The part related is the path in create_dumpfile():

        if (!create_dump_bitmap())
                return FALSE;

        if (info->flag_split) {
                if ((status = writeout_multiple_dumpfiles()) == FALSE)
                        return FALSE;
        } else {
                if ((status = writeout_dumpfile()) == FALSE)
                        return FALSE;
        }

Now this part tries to do the task for a whole memory. So first this
needs to be generalized so that it does processing per range of
memory. If doing the processing three cycles, it would be as follows
pictorically in kdump-compressed format.
                                                
    +------------------------------------------+
    |    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
    |                                          |
    |                                          |
    +------------------------------------------+

where the portions except for page data are in fixed length; so I
wrote only page data differently.

For the processing of writing pages per range of memory, it's useful
to reuse the code for --split's splitting features that split a single
dumpfile into a multiple dumpfiles, which has prepared data strucutre
to have start and end page frame numbers of the corresponding dumped
memory. For example, see part below in write_kdump_pages().

        if (info->flag_split) {
                start_pfn = info->split_start_pfn;
                end_pfn   = info->split_end_pfn;
        }
        else {
                start_pfn = 0;
                end_pfn   = info->max_mapnr;
        }

        for (pfn = start_pfn; pfn < end_pfn; pfn++) {

For the processing of creating and referencing bitmaps per range of
memory, there's no functions that do that. The ones for a whole memory
only: create_bitmap() and is_dumpable(). Also, creating bitmap depends
on source dumpfile format. Trying with ELF to kdump-compressed format
case first seems most handy; or if usecase is on the 2nd kernel only,
this case is enough?)

For performance impact, I don't know that exactly. But I guess
iterating filtering processing is most significant. I don't know exact
data structure for each kind of memory, but if there's the ones
needing linear order to look up the data for a given page frame
number, there would be necessary to add some special handling not to
reduce performance.

Thanks.
HATAYAMA, Daisuke