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 X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 51F21C32754 for ; Fri, 2 Aug 2019 17:05:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 32F3A2173E for ; Fri, 2 Aug 2019 17:05:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404113AbfHBRFK (ORCPT ); Fri, 2 Aug 2019 13:05:10 -0400 Received: from foss.arm.com ([217.140.110.172]:55252 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2403954AbfHBRFJ (ORCPT ); Fri, 2 Aug 2019 13:05:09 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 120ED344; Fri, 2 Aug 2019 10:05:09 -0700 (PDT) Received: from [10.1.196.105] (eglon.cambridge.arm.com [10.1.196.105]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6082D3F575; Fri, 2 Aug 2019 10:05:08 -0700 (PDT) Subject: Re: [PATCH v2 15/24] EDAC, ghes: Extract numa node information for each dimm To: Robert Richter Cc: Borislav Petkov , Mauro Carvalho Chehab , "linux-edac@vger.kernel.org" , "linux-kernel@vger.kernel.org" References: <20190624150758.6695-1-rrichter@marvell.com> <20190624150758.6695-16-rrichter@marvell.com> From: James Morse Message-ID: Date: Fri, 2 Aug 2019 18:05:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <20190624150758.6695-16-rrichter@marvell.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Robert, On 24/06/2019 16:09, Robert Richter wrote: > In a later patch we want to have one mc device per node. This patch > extracts the numa node information for each dimm. This is done by > collecting the physical address ranges from the DMI table (Memory > Array Mapped Address - Type 19 of SMBIOS spec). The node information > for a physical address is already know to a numa aware system (e.g. by > using the ACPI _PXM method or the ACPI SRAT table), so based on the PA > we can assign the node id to the dimms. I really don't like the way this depends on the rest of the kernel's NUMA support. mm's policies around the placement of data change with these settings, that shouldn't matter here. Reporting physical errors shouldn't be influenced by mm's placement policy. pfn_valid() is a sore subject on arm64, it will return false for random pages that the firmware is using, or wrote data to with unusual memory attributes. Depending on it makes this code fragile... > A fallback that disables numa is implemented in case the node > information is inconsistent. ... which is why you need a fallback. All this makes it difficult to explain why this things view of memory is as it is. Making the RAS/edac code unpredictable like this is a hard sell. You need to squint through Kconfig, SRAT and the UEFI memory map. (due to pfn_valid(): the behaviour here can change over a reboot) Can we 'just' use the type-16 handle to group the DIMMs? As an illustration: http://www.linux-arm.org/git?p=linux-jm.git;a=shortlog;h=refs/heads/edac_ghes_2level_dimms/v0 This reflects the SMBIOS tables on my NUMA desktop, and doesn't depend on any of the above. I'd be interested to know what is missing from this approach. (which numa node? I don't think we need to know the mapping of mcX<->nid up front. We can find it from the faulting physical address when we get an error report). N.B, your mail is still arriving base64 encoded. It looks like this: https://lore.kernel.org/linux-edac/20190624150758.6695-16-rrichter@marvell.com/raw Lei Wang found: > Ah I found if without explicit "--transfer-encoding=7bit" when do "git > send-mail", my ubuntu box sent out base64 by default. (but his mail didn't get archived for some reason) Thanks, James