在 2023/12/1 16:08, HAGIO KAZUHITO(萩尾 一仁) 写道:
On 2023/11/30 17:26, Shijie Huang wrote:
Hi Kazu,
在 2023/11/30 15:29, HAGIO KAZUHITO(萩尾 一仁) 写道:
On 2023/11/30 16:21, HAGIO KAZUHITO(萩尾 一仁) wrote:
thanks for the patch.
On 2023/11/28 12:41, Huang Shijie wrote:
If the kernel exports the vmmemap then we can use that symbol in
crash to optimize access. vmmemap is just an array of page structs
after all.
This patch tries to get the "vmemmap" from the vmcore file.
If we can use the "vmemmap", use the vmemmap_is_page_ptr to replace
the generic_is_page_ptr().
I recalled that I also did a similar thing for x86_64 [1] in the past..
so it's not so slow on x86_64 and it has valid section check too.
Maybe your vmlinux is not so big as mine(441M)...
It's not so small :)
crash> files | grep -m1 vmlinux
5 ffff97c21fa2cf00 ffff97c2400e5200 ffff97c0f5cf5ec8 REG
/usr/lib/debug/usr/lib/modules/4.18.0-305.el8.x86_64/vmlinux
crash> !ls -lh /usr/lib/debug/usr/lib/modules/4.18.0-305.el8.x86_64/vmlinux
-rwxr-xr-x. 3 root root 826M Apr 29 2021
/usr/lib/debug/usr/lib/modules/4.18.0-305.el8.x86_64/vmlinux
crash> files -n ffff97c0f5cf5ec8 | ts.py
16:42:30.902 START
16:42:30.902 INODE NRPAGES
16:42:30.902 ffff97c0f5cf5ec8 211283
16:42:30.902
16:42:31.106 NODE PAGES
16:42:31.106 0 211283
16:42:31.106 END (ELAPS 0:00:00.204)
Really fast.
(This crash has your "files -n" v2 patch and is_page_ptr() check at the
beginning of summary_inode_page)
[1]
https://github.com/crash-utility/crash/commit/4141373d9de3fea29f5d2b58f60e44bc132726c0
I don't object to add an entry to vmcoreinfo as a way of getting the
vmemmap value. Seems like arm64 has another value from VMEMMAP_START.
but there are some concerns in crash:
- machdep->flags already has VMEMMAP flag. It's used like "if
(IS_SPARSEMEM() && (machdep->flags & VMEMMAP)" e.g. [1]. Adding the new
flag is very confusing and inconsistent.
- Do all architectures have VMEMMAP_VADDR/END values in crash with
CONFIG_SPARSEMEM_VMEMMAP configured?
yes. your concern are right. I found some arch does not support the
VMEMMAP_VADDR/END.
So it is better to add this into ARM64 first. (I use the arm64 machine
all the time..)
we cannot test all archs, so this kind of arch-independent change makes
me nervous. I would like to suggest an arch-specific use first. e.g.
how about making x86_64_is_page_ptr more generic and use it?
I will add arm64 version code. I am not familar with x86, and I do not
have x86 machine for the testing.
so it's better to not change it.
OK, I see.
What happens if you use it on arm64? maybe the valid section can check
it with VMEMMAP_VADDR without the vmemmap value. Just an idea though.
hmm sorry, probably this does not work, I missed this.
+ pfn = (addr - vt->vmemmap) / size;
The code is converted by the linux code:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/asm-generic/memory_model.h?h=v6.7-rc3#n38
#define __page_to_pfn(page) (unsigned long)((page) - vmemmap)
So it's correct.
but can VMEMMAP_VADDR and phys_offset can be used to get vmemmap value
on arm64?
On arm64, I can get vmemmap by parsing "memstart_addr".
But I cannot know if CONFIG_SPARSEMEM_VMEMMAP is enabled.
on x86_64, vmemmap_populate is used:
if (symbol_exists("vmemmap_populate"))
machdep->flags |= VMEMMAP;
on arm64, it's set unconditionally, is it ok?
It is really set unconditionally. I do not know why?
arm64_init(int when)
{
...
case PRE_GDB:
...
machdep->stacksize = ARM64_STACK_SIZE;
machdep->flags |= VMEMMAP;
So if the kernel can export "vmemmap", everything become easy.
All the archs supporting the VMEMMAP can benifit from it, such as arm64,
ppc,loongarch,riscv..
Yes but we're not sure whether the users of the other archs have the
same issue (e.g. x86_64 is fast enough) and it's hard to test all archs.
Also, crash cannot always access vmcoreinfo (e.g. ramdumps), basically
it's better to implement without depending on vmcoreinfo first if
okay. But I use crash with vmcoreinfo(/proc/kcore) all the time:
1.) Test the performance
2.) Debug the linux kernel.
So I improve the vmcoreinfo to run the crash faster..
possible. If there is a case where crash cannot work without
vmcoreinfo, then we will add a entry though.
Thanks
Huang Shijie
Thanks,
Kazu
--
Crash-utility mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxxxxxx
https://${domain_name}/admin/lists/devel.lists.crash-utility.osci.io/
Contribution Guidelines: https://github.com/crash-utility/crash/wiki
