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
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/crash-utility
Contribution Guidelines: https://github.com/crash-utility/crash/wiki
