Re: [Crash-utility] [External Mail]Re: zram decompress support for gcore/crash-utility
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(a)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!******/#