For example, I have a vmcore file which is over 23G,
and the panic kernel had 767.6G memory,
its max_sect_len is 4468736.
Current code costs too much time to do the following loop:
..............................................
for (i = 1; i < max_sect_len + 1; i++) { dd->valid_pages[i] = dd->valid_pages[i - 1];
for (j = 0; j < BITMAP_SECT_LEN; j++, pfn++) if (page_is_dumpable(pfn)) dd->valid_pages[i]++;
..............................................
For my case, it costs about 56 seconds to finish the
big loop.
This patch moves the hweightXX macros to defs.h,
and uses hweight64 to optimize the loop.
For my vmcore, the loop only costs about one second now.
diskdump: use mmap/madvise to improve the start-up
Sometimes, the size of bitmap in vmcore can be very large, such as over
256M. This patch uses mmap/madvise to improve the performance of reading
bitmap in the non-FLAT_FORMAT code path.
Without the patch:
#echo 3 > /proc/sys/vm/drop_caches;
#time ./crash -i ./commands.txt /root/t/vmlinux /root/t/vmcore > /dev/null 2>&1
............................
real 0m55.217s
user 0m15.114s
sys 0m3.560s
............................
With the patch:
#echo 3 > /proc/sys/vm/drop_caches;
#time ./crash -i ./commands.txt /root/t/vmlinux /root/t/vmcore > /dev/null 2>&1
............................
real 0m44.097s
user 0m19.031s
sys 0m1.620s
............................
When arm64 is configured with PAGE_SIZE=4k and 4 level
translation, the pagetable of all pages may be created with
block mapping or contiguous mapping as much as possible, likes
disable CONFIG_RODATA_FULL_DEFAULT_ENABLED. But now, vtop
command can not handle 1GB block (PUD mapping) well, and just
shows a seek error:
Fix for "kmem -s|-S" on Linux 5.17+ with CONFIG_SLAB
Since the following kernel commits split slab info from struct page
into struct slab, crash cannot get several slab related offsets from
struct page.
d122019bf061 ("mm: Split slab into its own type")
401fb12c68c2 ("mm: Differentiate struct slab fields by sl*b implementations")
07f910f9b729 ("mm: Remove slab from struct page")
Without the patch, "kmem -s|-S" options cannot work correctly on kernels
configured with CONFIG_SLAB with the following error:
The commit <cd8954023bd4> broke crash-utility on s390x and got the
following error:
crash: cannot resolve ".rodata"
The reason is that all symbols containing a "." may be filtered out
on s390x. To prevent the current failure, do not filter out the
symbol ".rodata" on s390x.
In addition, a simple way is to check whether the symbol ".rodata"
exists before calculating the value of a symbol, just to be on the
safe side.
Fixes: 7d34768896a6 ("kernel: fix start-up time degradation caused by strings command")
Reported-by: Alexander Egorenkov <email address hidden>
Signed-off-by: Lianbo Jiang <email address hidden>
7d34768...
by
HATAYAMA Daisuke <email address hidden>
kernel: fix start-up time degradation caused by strings command
verify_namelist() uses strings command and scans full part of vmlinux
file to find linux_banner string. However, vmlinux file is quite large
these days, reaching over 500MB. As a result, this degradates start-up
time of crash command 10 or more seconds. (Of course, this depends on
machines you use for investigation, but I guess typically we cannot
use such powerful machines to investigate crash dump...)
To resolve this issue, let's use bfd library and read linux_banner
string in vmlinux file directly.
The reason is that the PTOV() and arm64_vtop_4level_4k() do not work
as expected due to incorrect physvirt_offset.
To fix the above issue, need to read out the virtual address of
"physvirt_offset" from the "/proc/kallsyms", and update the
ms->phys_offset which is initialized with a wrong value in kernel
version [5.4, 5.10).
arm64: use the vmcore info to get module/vmalloc/vmemmap ranges
Since the kernel commit <2369f171d5c5> ("arm64: crash_core: Export
MODULES, VMALLOC, and VMEMMAP ranges"), crash can obtain the range
of module/vmalloc/vmemmap from the vmcore info, and no need to
calculate them manually.
This patch adds a new hook arm64_get_range_v5_18 which could parse
out all the module/vmalloc/vmemmap ranges from the vmcore info.
