Glad you found it. Any thoughts/reactions? EM Sent from my iPhone > On Nov 29, 2022, at 12:17 AM, lizhijian@xxxxxxxxxxx wrote: > > > >> On 28/11/2022 23:03, Eliot Moss wrote: >>> 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): > > I found it :) at > https://www.mail-archive.com/nvdimm@xxxxxxxxxxxxxxx/msg02743.html > > >> ================================================================================ >> 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 _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
