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 5814BC433FE for ; Mon, 28 Nov 2022 15:04:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AF7FD6B0072; Mon, 28 Nov 2022 10:04:24 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AA7B86B0073; Mon, 28 Nov 2022 10:04:24 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 96F5A6B0074; Mon, 28 Nov 2022 10:04:24 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 81DB96B0072 for ; Mon, 28 Nov 2022 10:04:24 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id DB443C0E58 for ; Mon, 28 Nov 2022 15:04:23 +0000 (UTC) X-FDA: 80183172006.30.7E8E8C9 Received: from mailsrv.cs.umass.edu (mailsrv.cs.umass.edu [128.119.240.136]) by imf26.hostedemail.com (Postfix) with ESMTP id 15E7A140107 for ; Mon, 28 Nov 2022 15:03:35 +0000 (UTC) Received: from [192.168.50.148] (c-24-62-201-179.hsd1.ma.comcast.net [24.62.201.179]) by mailsrv.cs.umass.edu (Postfix) with ESMTPSA id 3043E4010229; Mon, 28 Nov 2022 10:03:35 -0500 (EST) Message-ID: Date: Mon, 28 Nov 2022 10:03:35 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Reply-To: moss@cs.umass.edu Subject: Re: nvdimm,pmem: makedumpfile: __vtop4_x86_64: Can't get a valid pte. Content-Language: en-US To: "lizhijian@fujitsu.com" , "kexec@lists.infradead.org" , "linux-mm@kvack.org" , "nvdimm@lists.linux.dev" Cc: "dan.j.williams@intel.com" References: <103666d5-3dcf-074c-0057-76b865f012a6@cs.umass.edu> <35997834-f6d2-0fc6-94a1-a7a25559d5ef@fujitsu.com> From: Eliot Moss In-Reply-To: <35997834-f6d2-0fc6-94a1-a7a25559d5ef@fujitsu.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669647817; a=rsa-sha256; cv=none; b=sqmKnFzDvP5zw7zv5GvDzyCfO2KPE4+CrFLwTQe+u6KlMtIF5FmZGyXlMJSUvvNnrn3AWD +JRACkcOWDcSiIfraAI5twcXdNXuPhHXiXM9ySUiq5K0eN/HXl9mkDMqOwOvl6By8jQhl7 Zz7kQQUerTrZH7sSSvwAY1uF1g/Ptr0= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf26.hostedemail.com: domain of moss@cs.umass.edu designates 128.119.240.136 as permitted sender) smtp.mailfrom=moss@cs.umass.edu ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669647817; h=from:from:sender:reply-to: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=5nf1q05IrAg2VHI4eg2FFStnB/kOKLSOPLTgU6ddRpc=; b=X3z2aaSQudLxgO/XFJgOgQ4hPdj+848eaymf7roEEl3MoHqdOaHZ2AvTOmGn9KVgJhw7UC UEZ+g3NyV9LvxtSiPr/nkR21JNhi1hmfbQ8KHssGnufbhhlnYqhOcf2GfHl6IP/5C2TshT uWsaOxt2B1Z7+nRgaisSryNRQguGPOs= X-Rspam-User: Authentication-Results: imf26.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf26.hostedemail.com: domain of moss@cs.umass.edu designates 128.119.240.136 as permitted sender) smtp.mailfrom=moss@cs.umass.edu X-Stat-Signature: qp17d8k9s5axmenggmujwaw1w9z3rckz X-Rspamd-Queue-Id: 15E7A140107 X-Rspamd-Server: rspam12 X-HE-Tag: 1669647815-289153 X-Bogosity: Ham, tests=bogofilter, spamicity=0.145882, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 11/28/2022 9:46 AM, lizhijian@fujitsu.com wrote: > > > On 28/11/2022 20:53, Eliot Moss wrote: >> On 11/28/2022 7:04 AM, lizhijian@fujitsu.com 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