[PATCH] makedumpfile: change the wrong code to calculate bufsize_cyclic for elf dump

Atsushi Kumagai kumagai-atsushi at mxc.nes.nec.co.jp
Thu May 8 22:35:13 PDT 2014


>>I am wondering if we are doing anything which requires kernel to allocate
>>memory and that leads to OOM.
>
>max_usage_in_bytes seems to include page cache, so I used simpler way
>like the patch at the bottom of this mail instead.
>
>Here is the result:
>
>            parameter                  |      result
> dump_lv | buffer[KiB] |  mmap (=4MiB) |    VmHWM [KiB]
> --------+-------------+---------------+------------------
>    d31  |       1     |       on      |        5872
>   Ed31  |       1     |       on      |        5804
>    d31  |       1     |      off      |        1784
>   Ed31  |       1     |      off      |        1720
>    d31  |    1000     |       on      |        8884  (*1)
>   Ed31  |    1000     |       on      |        7812
>    d31  |    1000     |      off      |        4788  (*1)
>   Ed31  |    1000     |      off      |        3720
>
>  *1. 2nd bitmap is allocated twice by the bug found by Arthur Zou.
>
>According to this result and the estimation below produced from the
>design of makedumpfile,
>
>  base size + (buffer size * 2) + (for mmap size) = VmHWM
>
>the base size may be about 2 MB, so about 6MB (base + mmap) will
>be the deadline. If 20% of the available memory is less than 6MB,
>OOM will happen.
>As for Baoquan's case, remained 17.2MB sounds enough even if
>makedumpfile consumes 6MB as for the other works.
>So I don't know why OOM happened yet, but the current safety
>limit looks still reasonable to me at least.
>
>By the way, I noticed it's better to remove 4MB(for mmap)
>from the available memory before calculate the bitmap buffer
>size. I'll do this anyway.

Sorry, I did my test on a 1st kernel environment.
The dump file was on a disk and I used mmap() for it, so __do_fault()
occurred and the VmHWM (MAX(MM_FILEPAGES + MM_ANONPAGES)) increased
by 4MB.

Here is the result on a 2nd kernel environment:

             parameter                  |      result
  dump_lv | buffer[KiB] |  mmap (=4MiB) |    VmHWM [KiB]
  --------+-------------+---------------+------------------
     d31  |       1     |       on      |         776
    Ed31  |       1     |       on      |         712
     d31  |       1     |      off      |         704
    Ed31  |       1     |      off      |         708
     d31  |    1000     |       on      |        1776
    Ed31  |    1000     |       on      |        2716
     d31  |    1000     |      off      |        1660
    Ed31  |    1000     |      off      |        2556


According to this, I think there is no need to take care of the memory
usage of mmap() because the actual memory usage is small enough.


Thanks
Atsushi Kumagai



More information about the kexec mailing list