On 11/28/2022 9:46 AM, lizhijian@xxxxxxxxxxx wrote:
On 28/11/2022 20:53, Eliot Moss wrote:
On 11/28/2022 7:04 AM, lizhijian@xxxxxxxxxxx wrote:
Hi folks,
I'm going to make crash coredump support pmem region. So
I have modified kexec-tools to add pmem region to PT_LOAD of vmcore.
But it failed at makedumpfile, log are as following:
In my environment, i found the last 512 pages in pmem region will cause the error.
I wonder if an issue I reported is related: when set up to map
2Mb (huge) pages, the last 2Mb of a large region got mapped as
4Kb pages, and then later, half of a large region was treated
that way.
Could you share the url/link ? I'd like to take a look
It was in a previous email to the nvdimm list. the title was:
"Possible PMD (huge pages) bug in fs dax"
And here is the body. I just sent directly to the list so there
is no URL (if I should be engaging in a different way, please let me know):
================================================================================
Folks - I posted already on nvdimm, but perhaps the topic did not quite grab
anyone's attention. I had had some trouble figuring all the details to get
dax mapping of files from an xfs file system with underlying Optane DC memory
going, but now have that working reliably. But there is an odd behavior:
When first mapping a file, I request mapping a 32 Gb range, aligned on a 1 Gb
(and thus clearly on a 2 Mb) boundary.
For each group of 8 Gb, the first 4095 entries map with a 2 Mb huge (PMD)
page. The 4096th one does FALLBACK. I suspect some problem in
dax.c:grab_mapping_entry or its callees, but am not personally well enough
versed in either the dax code or the xarray implementation to dig further.
If you'd like a second puzzle 😄 ... after completing this mapping, another
thread accesses the whole range sequentially. This results in NOPAGE fault
handling for the first 4095+4095 2M regions that previously resulted in
NOPAGE -- so far so good. But it gives FALLBACK for the upper 16 Gb (except
the two PMD regions it alrady gave FALLBACK for).
I can provide trace output from a run if you'd like and all the ndctl, gdisk
-l, fdisk -l, and xfs_info details if you like.
In my application, it would be nice if dax.c could deliver 1 Gb PUD size
mappings as well, though it would appear that that would require more surgery
on dax.c. It would be somewhat analogous to what's already there, of course,
but I don't mean to minimize the possible trickiness of it. I realize I
should submit that request as a separate thread 😄 which I intend to do
later.
================================================================================
Regards - Eliot Moss
