Re: [Crash-utility] [PATCH] diskdump: use mmap/madvise to improve the start-up
Hi Kazu,
On Mon, Apr 04, 2022 at 07:44:09AM +0000, HAGIO KAZUHITO(萩尾 一仁) wrote:
-----Original Message-----
> 1.) The bitmap of vmcore file can be very big in the server kernel panic,
> such as over 256M.
>
> This patch uses mmap/madvise to improve the read speed
> of the bitmap in the non-FLAT_FORMAT code path.
>
> Use MADV_SEQUENTIAL for madvise, it will trigger aggressively
> readahead for reading the bitmap.
I'm not familiar with the detailed behavior of madvise() and a little
concerned about the sentence "may be freed soon after they are accessed"
below:
MADV_SEQUENTIAL
Expect page references in sequential order. (Hence, pages in
the given range can be aggressively read ahead, and may be freed
soon after they are accessed.)
MADV_WILLNEED
Expect access in the near future. (Hence, it might be a good
idea to read some pages ahead.)
dd->bitmap is often used after the initialization process, is there
no side-effect?
I am not sure.
IMHO, the side-effect can be ignored.
1.) In the original code, dd->bitmap is malloced,
so it is anonymous page in the kernel, can be swapped to disk.
2.) If we use mmap, dd->bitmap is page cache in the kernel.
It can be freed, and also can be read back again if we access it.
So if MADV_WILLNEED has same or some good effect, I think it will be
easier to accept. Any benchmark and information?
I tested the MADV_WILLNEED, it is
really better then the MADV_SEQUENTIAL.
The following is the benchmark(tested three times for each case):
1.) the origin code costs about 29s to read out all the bitmap.
2.) Use the MADV_SEQUENTIAL, the read(caused by memcpy) costs
about 17s.
3.) Use the MADV_WILLNEED, the read(caused by the memcpy) costs
about 14s.
Thanks
Huang Shijie