From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4DE75C4321E for ; Tue, 29 Nov 2022 13:41:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AD6556B0072; Tue, 29 Nov 2022 08:41:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A86B16B0078; Tue, 29 Nov 2022 08:41:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 976B56B007D; Tue, 29 Nov 2022 08:41:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 88EAB6B0072 for ; Tue, 29 Nov 2022 08:41:52 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id ACB2A1A071A for ; Tue, 29 Nov 2022 05:22:56 +0000 (UTC) X-FDA: 80185335552.13.EE5A782 Received: from mailsrv.cs.umass.edu (mailsrv.cs.umass.edu [128.119.240.136]) by imf05.hostedemail.com (Postfix) with ESMTP id 3FD7B100002 for ; Tue, 29 Nov 2022 05:22:56 +0000 (UTC) Received: from smtpclient.apple (c-24-62-201-179.hsd1.ma.comcast.net [24.62.201.179]) by mailsrv.cs.umass.edu (Postfix) with ESMTPSA id 79307401AF67; Tue, 29 Nov 2022 00:22:55 -0500 (EST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Eliot Moss Mime-Version: 1.0 (1.0) Subject: Re: nvdimm,pmem: makedumpfile: __vtop4_x86_64: Can't get a valid pte. Date: Tue, 29 Nov 2022 00:22:44 -0500 Message-Id: <70F971CF-1A96-4D87-B70C-B971C2A1747C@roc.cs.umass.edu> References: Cc: Moss@cs.umass.edu, kexec@lists.infradead.org, linux-mm@kvack.org, nvdimm@lists.linux.dev, dan.j.williams@intel.com In-Reply-To: To: lizhijian@fujitsu.com X-Mailer: iPhone Mail (20B101) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669699376; a=rsa-sha256; cv=none; b=zetDXWgCEOaUJg8JI8VPgMKN/1oMgsH1lVrlbbNVrdo46TBtWfQIuMSOkKRKXtd0SKLWwP OTErZbjgDDHZp0aFp2e4hnYycVwYMU75/qEqbusjfzyJQan20a6EcAUnrjnnm8D46Dleqq 9MHPtZSK5HbzK6GXowmwUsyv2be0iZQ= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=none; dmarc=none; spf=none (imf05.hostedemail.com: domain of moss@roc.cs.umass.edu has no SPF policy when checking 128.119.240.136) smtp.mailfrom=moss@roc.cs.umass.edu ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669699376; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=41TTk9lkDl+pcqRxwQmKSyauANEeCH7RvbNGoVpnCVA=; b=pkPBeMHhR3sZpHJRW0yaNgEhaLCBLrNhLVvlsHJoUdzWEQoNU9dJl639qR8HaWBR+BHhgW vMf8VxceCGn0PLlv+2sVJgToJWivGB3HI27hWCCDwZejcOBtLnrgDNMOvsVDFp/G2zOnCf yfYAEaKohCTorBkWvL9wpy8roBaxN0Y= X-Rspamd-Queue-Id: 3FD7B100002 X-Rspam-User: Authentication-Results: imf05.hostedemail.com; dkim=none; dmarc=none; spf=none (imf05.hostedemail.com: domain of moss@roc.cs.umass.edu has no SPF policy when checking 128.119.240.136) smtp.mailfrom=moss@roc.cs.umass.edu X-Rspamd-Server: rspam09 X-Stat-Signature: yb1jjp7wa8pe6q1an1brqz7qify31919 X-HE-Tag: 1669699376-692352 X-Bogosity: Ham, tests=bogofilter, spamicity=0.040445, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Glad you found it. Any thoughts/reactions? EM Sent from my iPhone > On Nov 29, 2022, at 12:17 AM, lizhijian@fujitsu.com wrote: >=20 > =EF=BB=BF >=20 >> On 28/11/2022 23:03, Eliot Moss wrote: >>> On 11/28/2022 9:46 AM, lizhijian@fujitsu.com wrote: >>>=20 >>>=20 >>> On 28/11/2022 20:53, Eliot Moss wrote: >>>> On 11/28/2022 7:04 AM, lizhijian@fujitsu.com wrote: >>>>> Hi folks, >>>>>=20 >>>>> 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. >>>>>=20 >>>>> But it failed at makedumpfile, log are as following: >>>>>=20 >>>>> In my environment, i found the last 512 pages in pmem region will caus= e the error. >>>>=20 >>>> 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. >>>>=20 >>> Could you share the url/link ? I'd like to take a look >>=20 >> It was in a previous email to the nvdimm list. the title was: >>=20 >> "Possible PMD (huge pages) bug in fs dax" >>=20 >> 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= ): >=20 > I found it :) at > https://www.mail-archive.com/nvdimm@lists.linux.dev/msg02743.html >=20 >=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >> Folks - I posted already on nvdimm, but perhaps the topic did not quite g= rab >> anyone's attention. I had had some trouble figuring all the details to g= et >> dax mapping of files from an xfs file system with underlying Optane DC me= mory >> going, but now have that working reliably. But there is an odd behavior:= >>=20 >> 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. >>=20 >> 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 enoug= h >> versed in either the dax code or the xarray implementation to dig further= . >>=20 >>=20 >> If you'd like a second puzzle =F0=9F=98=84 ... after completing this mapp= ing, another >> thread accesses the whole range sequentially. This results in NOPAGE fau= lt >> 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 (exc= ept >> the two PMD regions it alrady gave FALLBACK for). >>=20 >>=20 >> I can provide trace output from a run if you'd like and all the ndctl, gd= isk >> -l, fdisk -l, and xfs_info details if you like. >>=20 >>=20 >> 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 sur= gery >> on dax.c. It would be somewhat analogous to what's already there, of cou= rse, >> but I don't mean to minimize the possible trickiness of it. I realize I >> should submit that request as a separate thread =F0=9F=98=84 which I inte= nd to do >> later. >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>=20 >> Regards - Eliot Moss