[Crash-utility] [External Mail]Re: zram decompress support for gcore/crash-utility
赵乾利
zhaoqianli at xiaomi.com
Wed Apr 1 14:58:07 UTC 2020
Hi,Dave
zram is same with other swap device,but every swaped page will be compressed then saved to another memory address.
The process is same with the common swap device,non-swap just a normal user address,pgd and mmu will translate to phy address
please refer to below information:
crash> vm -p
PID: 1565 TASK: ffffffe1fce32d00 CPU: 7 COMMAND: "system_server"
MM PGD RSS TOTAL_VM
ffffffe264431c00 ffffffe1f54ad000 528472k 9780384k
VMA START END FLAGS FILE
ffffffe0ea401300 12c00000 12e00000 100073
VIRTUAL PHYSICAL
...
144fc000 SWAP: /dev/block/zram0 OFFSET: 236750
...
1738e000 SWAP: /dev/block/zram0 OFFSET: 73426
1738f000 21aa2c000
17390000 1c3308000
17391000 SWAP: /dev/block/zram0 OFFSET: 73431
17392000 19c162000
17393000 19c132000
17394000 SWAP: /dev/block/zram0 OFFSET: 234576
17395000 19c369000
17396000 20b35c000
17397000 18011e000
17398000 SWAP: /dev/block/zram0 OFFSET: 73433
17399000 1dc3d2000
1739a000 1bc59f000
1739b000 SWAP: /dev/block/zram0 OFFSET: 73437
crash> vtop -c 1565 144fc000
VIRTUAL PHYSICAL
144fc000 (not mapped)
PAGE DIRECTORY: ffffffe1f54ad000
PGD: ffffffe1f54ad000 => 1f54ab003
PMD: ffffffe1f54ab510 => 1f43b8003
PTE: ffffffe1f43b87e0 => 39cce00
PTE SWAP OFFSET
39cce00 /dev/block/zram0 236750
VMA START END FLAGS FILE
ffffffe148bafe40 144c0000 14540000 100073
SWAP: /dev/block/zram0 OFFSET: 236750
________________________________________
From: Dave Anderson <anderson at redhat.com>
Sent: Wednesday, April 1, 2020 22:20
To: d hatayama
Cc: 赵乾利; Discussion list for crash utility usage, maintenance and development
Subject: [External Mail]Re: [Crash-utility] zram decompress support for gcore/crash-utility
----- Original Message -----
...
> >
> > As far as the gcore extension module, that is maintained by Daisuke Hatayama,
> > and he make all decisions w/respect to that codebase. I've cc'd this response
> > to him.
>
> Thanks Zhao for your patch set.
> Thanks for ccing me, Dave.
>
> I agree that ZRAM support is useful as your explanation. On the other
> hand, it is not only for crash gcore command, but also for crash utility. I think
> it more natural than the current implementation of your patch set that you
> implement a ZRAM support in crash utility and then do it in crash gcore command.
>
> If the ZRAM support were transparent to readmem() interface, there would be no need
> to implement crash gcore command at all. If not, there would be need to add a new code
> for the ZRAM support just corresponding to the following stanza in
> 0001-gcore-add-support-zram-swap.patch:
>
> @@ -225,6 +417,18 @@ void gcore_coredump(void)
> strerror(errno));
> } else {
> pagefaultf("page fault at %lx\n", addr);
> + if (paddr != 0) {
> + pte_val = paddr;
> + if(try_zram_decompress(pte_val, (unsigned char *)buffer) == PAGE_SIZE)
> + {
> + error(WARNING, "zram decompress successed\n");
> + if (fwrite(buffer, PAGE_SIZE, 1, gcore->fp) != 1)
> + error(FATAL, "%s: write: %s\n", gcore->corename, strerror(errno));
> + continue;
> + }
> +
> + }
I'm not clear on how zram is linked into the user-space mapping. For user space that
has been swapped out to a zram swap device, I presume it's the same as is, but it
references the zram swap device. But for other user-space mappings (non-swapped),
what does the "vm -p" display for user space virtual address pages that are backed
by zram? And for that matter, what does "vtop <address>" show?
Thanks,
Dave
#/******本邮件及其附件含有小米公司的保密信息,仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件! This e-mail and its attachments contain confidential information from XIAOMI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!******/#
More information about the Crash-utility
mailing list