>>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
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
