Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp674715pxf; Wed, 17 Mar 2021 13:07:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx56m9kzi0bl0noC7juY6+uGw3RFlXLa35zra3rwIXOb40gQV53c5/ggQwArJySJV0buKAj X-Received: by 2002:a17:906:cecc:: with SMTP id si12mr37434903ejb.461.1616011670520; Wed, 17 Mar 2021 13:07:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616011670; cv=none; d=google.com; s=arc-20160816; b=E3rLP5/7qvlls6fQiCJFuZZLZIhiADCYTlSyNac4KZ+Gpzg7PBzgj1oSisgZ5mjB9m 0yYqHb9jf8iAuOzpfI/1+5G+1zXPDhECctUVSFc+NZm0oNHtS/guPQ1RB+wY4wqLXb0O g4qxzkt3VRoOxZ2kHoM2UMc0vctx6c4/47CmfaGYyDRCCScBUUzzhbT0PFnTp8wkvaou +3/1vwohU/hAvK+Pn950ckiKannfaJWB2beXIPgL9590y+aiLVXRcS5xoMy0e2tfsBJx b/hTlkdFoJL6E2vQ3jH4QdbhhY+JakHPAXO+kzMgRjK/6A/5ooWL78cTn1nnnOu4Y41S WJnA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=1MnlOAxSn54eoWUejaLjnmZ8eDHTdxhnEKkJD92D8Xw=; b=cWxflAVkqwc6qXfGebrWjdlyMYSAoQu6RGeM0DtHkNk7riDTyG8dwuZRuRB1OncdPp YpjCyd4kayGg6HirEYq1eJoGA/8uhfkd6XrqSmYQKGBJgdCMl6j/SGw3gN24hSOwDxDv 65aV+AMIN++hdQWwp/SF8pJ2wcxptJxz2VStR0m78d85q18yXXXi8GBu+1nR/xB2zobS qgJhlfcZY6waTDHo8D/KNw00JaG2i24QEwxyXnvQ+dXs7PYBOY/nz6iOLycM/lFKHgv9 DXeDtaukbW7ZkaXZaQWpb7zKzVpOQ+VDTlKfj/eZAP0pnM8eCSkl0TVZZLV/MX41e5wY HV9w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id fx8si17077440ejb.481.2021.03.17.13.07.27; Wed, 17 Mar 2021 13:07:50 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233279AbhCQUEi (ORCPT + 99 others); Wed, 17 Mar 2021 16:04:38 -0400 Received: from foss.arm.com ([217.140.110.172]:45690 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232499AbhCQUEL (ORCPT ); Wed, 17 Mar 2021 16:04:11 -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 9ECD51FB; Wed, 17 Mar 2021 13:04:10 -0700 (PDT) Received: from e113632-lin (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B6D223F70D; Wed, 17 Mar 2021 13:04:09 -0700 (PDT) From: Valentin Schneider To: John Paul Adrian Glaubitz Cc: "Peter Zijlstra \(Intel\)" , Linux Kernel Mailing List , "linux-ia64\@vger.kernel.org" , Sergei Trofimovich , debian-ia64 Subject: Re: [PATCH 0/1] sched/topology: NUMA distance deduplication In-Reply-To: References: <255d6b5d-194e-eb0e-ecdd-97477a534441@physik.fu-berlin.de> <8735wtr2ro.mognet@arm.com> Date: Wed, 17 Mar 2021 20:04:07 +0000 Message-ID: <87zgz1pmx4.mognet@arm.com> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 17/03/21 20:47, John Paul Adrian Glaubitz wrote: > Helo Valentin! > > On 3/17/21 8:36 PM, Valentin Schneider wrote: >> I see ACPI in your boot logs, so I'm guessing you have a bogus SLIT table >> (the ACPI table with node distances). You should be able to double check >> this with something like: >> >> $ acpidump > acpi.dump >> $ acpixtract -a acpi.dump >> $ iasl -d *.dat >> $ cat slit.dsl > > There does not seem to be a SLIT table in my firmware: > > root@glendronach:~# acpidump > acpi.dump > root@glendronach:~# acpixtract -a acpi.dump > > Intel ACPI Component Architecture > ACPI Binary Table Extraction Utility version 20200925 > Copyright (c) 2000 - 2020 Intel Corporation > > acpixtract(31194): unaligned access to 0x60000fffff9b3925, ip=0x4000000000003e91 > SSDT - 3768 bytes written (0x00000EB8) - ssdt1.dat > acpixtract(31194): unaligned access to 0x60000fffff9b3925, ip=0x4000000000003e00 > acpixtract(31194): unaligned access to 0x60000fffff9b3925, ip=0x4000000000003e91 > SPCR - 80 bytes written (0x00000050) - spcr.dat > acpixtract(31194): unaligned access to 0x60000fffff9b3925, ip=0x4000000000003e00 > acpixtract(31194): unaligned access to 0x60000fffff9b3925, ip=0x4000000000003e91 > APIC - 200 bytes written (0x000000C8) - apic.dat > SSDT - 1110 bytes written (0x00000456) - ssdt2.dat > SSDT - 316 bytes written (0x0000013C) - ssdt3.dat > SPMI - 80 bytes written (0x00000050) - spmi.dat > DSDT - 58726 bytes written (0x0000E566) - dsdt.dat > SSDT - 312 bytes written (0x00000138) - ssdt4.dat > SSDT - 2150 bytes written (0x00000866) - ssdt5.dat > SSDT - 316 bytes written (0x0000013C) - ssdt6.dat > SSDT - 3768 bytes written (0x00000EB8) - ssdt7.dat > FACP - 244 bytes written (0x000000F4) - facp.dat > SSDT - 1203 bytes written (0x000004B3) - ssdt8.dat > CPEP - 52 bytes written (0x00000034) - cpep.dat > SSDT - 316 bytes written (0x0000013C) - ssdt9.dat > DBGP - 52 bytes written (0x00000034) - dbgp.dat > SSDT - 3768 bytes written (0x00000EB8) - ssdt10.dat > FACS - 64 bytes written (0x00000040) - facs.dat > root@glendronach:~# > > root@glendronach:~# ls *.dsl *.dat > apic.dat cpep.dsl dsdt.dat facp.dsl spcr.dat spmi.dsl ssdt1.dat ssdt2.dsl ssdt4.dat ssdt5.dsl ssdt7.dat ssdt8.dsl > apic.dsl dbgp.dat dsdt.dsl facs.dat spcr.dsl ssdt10.dat ssdt1.dsl ssdt3.dat ssdt4.dsl ssdt6.dat ssdt7.dsl ssdt9.dat > cpep.dat dbgp.dsl facp.dat facs.dsl spmi.dat ssdt10.dsl ssdt2.dat ssdt3.dsl ssdt5.dat ssdt6.dsl ssdt8.dat ssdt9.dsl > root@glendronach:~# > Huh, then this might be some initialization fail that leaves nr_node_ids to MAX_NUMNODES, which must be 256 in your case (NODES_SHIFT==8). Devicetree can provide node distances, but something tells me you're not using that :-) >> a) Complain to your hardware vendor to have them fix the table and ship a >> firmware fix > > The hardware is probably too old for the vendor to care about fixing it. > Indeed, I only realized that after googling your machine >> b) Fix the ACPI table yourself - I've been told it's doable for *some* of >> them, but I've never done that myself >> c) Compile your kernel with CONFIG_NUMA=n, as AFAICT you only actually have >> a single node >> d) Ignore the warning >> >> >> c) is clearly not ideal if you want to use a somewhat generic kernel image >> on a wide host of machines; d) is also a bit yucky... > > Shouldn't the kernel be able to cope with quirky hardware? From what I remember in the past, > ACPI tables used to be broken quite a lot and the kernel contained workarounds for such cases, > didn't it? > Technically it *is* coping with it, it's just dumping the entire NUMA distance matrix in the process... Let me see if I can't figure out why your system doesn't end up with nr_node_ids=1. > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaubitz@debian.org > `. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913