>It indicates that the attached patch may not work well between kernel
>4.11 and 5.12, is it possible to encounter the similar issue(the
>nr_swapper_spaces may be optimized away)?
So i make a same questions before.
Maybe it is more reasonable to add both NR_SWAPCACHE and kernel version to resolve this problem?
If can not find nr_swapper_spaces, also have other choice to make this code more compatible.
Thanks!
Best regards
From: Lianbo Jiang <lijiang@xxxxxxxxxx>
Sent: Thursday, December 7, 2023 5:19:53 PM
To: HAGIO KAZUHITO(?尾 一仁); 薛国伦; devel@xxxxxxxxxxxxxxxxxxxxxxxxxxx
Cc: Johan.Erlandsson@xxxxxxxx
Subject: [External Mail]Re: [BUG FIXED]fix bug of CACHED in kmem -i show memory
Sent: Thursday, December 7, 2023 5:19:53 PM
To: HAGIO KAZUHITO(?尾 一仁); 薛国伦; devel@xxxxxxxxxxxxxxxxxxxxxxxxxxx
Cc: Johan.Erlandsson@xxxxxxxx
Subject: [External Mail]Re: [BUG FIXED]fix bug of CACHED in kmem -i show memory
[外部邮件] 此邮件来源于小米公司外部，请谨慎处理。若对邮件安全性存疑，请将邮件转发给misec@xxxxxxxxxx进行反馈
On 12/7/23 16:13, HAGIO KAZUHITO(?尾 一仁) wrote:
> On 2023/12/07 16:57, Lianbo Jiang wrote:
>
>>>> (gdb) p nr_swapper_spaces
>>>> $4 = <optimized out>
>>> Thank you folks, for the various information.
>>>
>>> Apparently the data of nr_swapper_spaces exists in the kernel, but its
>>> symbol does not exist. I think this means that we cannot calculate the
>>> number of pages from swapper_spaces[] with such a debuginfo, because we
>>> cannot get the array size of a swapper_spaces entry.
>> That's correct, Kazu.
>>
>>
>>> So I'd like to go with Johan's patch.
>>>
>>> cc -c -g -DX86_64 -DLZO -DSNAPPY -DGDB_10_2 memory.c -Wall -O2
>>> -Wstrict-prototypes -Wmissing-prototypes -fstack-protector
>>> -Wformat-security
>>> memory.c: In function dump_kmeminfo:
>>> memory.c:8612:50: warning: pointer targets in passing argument 2 of
>>> dump_vm_stat differ in signedness [-Wpointer-sign]
>>> 8612 | if (dump_vm_stat("NR_SWAPCACHE",
>>> &swapper_space_nrpages, 0)) {
>>> |
>>> ^~~~~~~~~~~~~~~~~~~~~~
>>> | |
>>> | ulong * {aka
>>> long unsigned int *}
>>> memory.c:298:33: note: expected long int * but argument is of type ulong
>>> * {aka long unsigned int *}
>>> 298 | static int dump_vm_stat(char *, long *, ulong);
>>> | ^~~~~~
>>>
>>> So with the following,
>>>
>>> - ulong swapper_space_nrpages;
>>> + long swapper_space_nrpages;
>> Looks good. Maybe the patch log also needs to be improved a little bit.
>>
>> Although the checking of kernel version looks not very good, seems no
>> better way.
> hmm, this sounds strange. My ack is for Johan's patch (attached), which
Ah, I did not see the attached patch. Thank you for pointing out this
issue, Kazu.
> does not have kernel version check, is this ok? sorry for confusing.
Sounds good idea if there is no kernel version check.
I still have one question: the following two commits were introduced
separately in kernel 5.12 and 4.11.
b6038942480e ("mm: memcg: add swapcache stat for memcg v2")
4b3ef9daa4fc ("mm/swap: split swap cache into 64MB trunks")
It indicates that the attached patch may not work well between kernel
4.11 and 5.12, is it possible to encounter the similar issue(the
nr_swapper_spaces may be optimized away)?
Thanks
Lianbo
>
> Johan, your patch does not have your Signed-off-by tag, could I have it?
>
> Thanks,
> Kazu
#/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ 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!******/#
On 12/7/23 16:13, HAGIO KAZUHITO(?尾 一仁) wrote:
> On 2023/12/07 16:57, Lianbo Jiang wrote:
>
>>>> (gdb) p nr_swapper_spaces
>>>> $4 = <optimized out>
>>> Thank you folks, for the various information.
>>>
>>> Apparently the data of nr_swapper_spaces exists in the kernel, but its
>>> symbol does not exist. I think this means that we cannot calculate the
>>> number of pages from swapper_spaces[] with such a debuginfo, because we
>>> cannot get the array size of a swapper_spaces entry.
>> That's correct, Kazu.
>>
>>
>>> So I'd like to go with Johan's patch.
>>>
>>> cc -c -g -DX86_64 -DLZO -DSNAPPY -DGDB_10_2 memory.c -Wall -O2
>>> -Wstrict-prototypes -Wmissing-prototypes -fstack-protector
>>> -Wformat-security
>>> memory.c: In function dump_kmeminfo:
>>> memory.c:8612:50: warning: pointer targets in passing argument 2 of
>>> dump_vm_stat differ in signedness [-Wpointer-sign]
>>> 8612 | if (dump_vm_stat("NR_SWAPCACHE",
>>> &swapper_space_nrpages, 0)) {
>>> |
>>> ^~~~~~~~~~~~~~~~~~~~~~
>>> | |
>>> | ulong * {aka
>>> long unsigned int *}
>>> memory.c:298:33: note: expected long int * but argument is of type ulong
>>> * {aka long unsigned int *}
>>> 298 | static int dump_vm_stat(char *, long *, ulong);
>>> | ^~~~~~
>>>
>>> So with the following,
>>>
>>> - ulong swapper_space_nrpages;
>>> + long swapper_space_nrpages;
>> Looks good. Maybe the patch log also needs to be improved a little bit.
>>
>> Although the checking of kernel version looks not very good, seems no
>> better way.
> hmm, this sounds strange. My ack is for Johan's patch (attached), which
Ah, I did not see the attached patch. Thank you for pointing out this
issue, Kazu.
> does not have kernel version check, is this ok? sorry for confusing.
Sounds good idea if there is no kernel version check.
I still have one question: the following two commits were introduced
separately in kernel 5.12 and 4.11.
b6038942480e ("mm: memcg: add swapcache stat for memcg v2")
4b3ef9daa4fc ("mm/swap: split swap cache into 64MB trunks")
It indicates that the attached patch may not work well between kernel
4.11 and 5.12, is it possible to encounter the similar issue(the
nr_swapper_spaces may be optimized away)?
Thanks
Lianbo
>
> Johan, your patch does not have your Signed-off-by tag, could I have it?
>
> 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
