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=-4.0 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 8DF18C4360F for ; Fri, 5 Apr 2019 15:43:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 590F92184B for ; Fri, 5 Apr 2019 15:43:17 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=intel-com.20150623.gappssmtp.com header.i=@intel-com.20150623.gappssmtp.com header.b="qWxjCJ2C" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731430AbfDEPnQ (ORCPT ); Fri, 5 Apr 2019 11:43:16 -0400 Received: from mail-oi1-f196.google.com ([209.85.167.196]:46584 "EHLO mail-oi1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726291AbfDEPnP (ORCPT ); Fri, 5 Apr 2019 11:43:15 -0400 Received: by mail-oi1-f196.google.com with SMTP id x188so5191505oia.13 for ; Fri, 05 Apr 2019 08:43:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sj5ur8Cq/BuzaN2ifegKjnKHNZadsvVGhfJ737scZtM=; b=qWxjCJ2C4YTGaRB9VBshlOczs86lXXi96/4MUM4KFNW57aHk+Y9NUay569AN2AVEAO Ew58BrpoYq3qi38QUMzCX4V3c6JMBwOQsD8Q/e6wvqNwRgeBKSLn5/AGWqh7sXQAyVFk MhYEexjZPJHL4F9KNMa+iE7I2xdyjpQ8lLA/rQjxnIZtVIhmnI3Tj/YRPtO2jUVyHBYV O8ZeJpoyAuDCVbZmR1CDJoKl4dtDEI2cMii1Vo/Jrz19wwDwZhGpZ7O4iApIt+QJwvDQ R0lacbsDF32fVMi22CzeDw38/8YGXp0LzKsO5dOflq27gqrNcwTw0QvEONmv7tyuEvaj X4RA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sj5ur8Cq/BuzaN2ifegKjnKHNZadsvVGhfJ737scZtM=; b=JB4tWbTrZxXwZE11DJO/KXt+Q97TyN4O/cqqUliV7RgQcUxtEPBQEzozb6Qzx+yIPJ ehZNBC+9JllkWpStaD0YeBjXeLWD3wuSb3qQY78X4ZVW7sOeN/+i9V/plDZqPRKCZFi/ +QEP3M6n2uHJUCmO5sEuK/biUre+yqepPkHhEje9mmkenHDAz525sRkee+FmbiyNhXFm mr8rhBgCRntKbkY21tvPvKzgHJu2Zwv86GgkzDEf+LTawaHKMNnB6Xxxh5JeXPc0mKmU oj56SJJgj0BAa9g6BRBhk0zRtRqHzE3k/u0bvolgXS8VAjQ8BjUfT4AuUGj+bYCFq4EB saCQ== X-Gm-Message-State: APjAAAXvxI2BduUHos4tm4MQBCAkN/9xnnF7qDVF6QDte4azYNY8+yNZ J2OvTPw8TMDfSKTfwwaZg2mfIHP4dwnihlvTAZ2fMw== X-Google-Smtp-Source: APXvYqwQIzEcgHJH2g95bHHSuUp6aFniNQQWMvFvEkdIRFFMM2bkcnOv77ZAMvXPrUVmGRcaUKHxXOM3RDJblZB6Pkg= X-Received: by 2002:aca:aa57:: with SMTP id t84mr7929156oie.149.1554478994621; Fri, 05 Apr 2019 08:43:14 -0700 (PDT) MIME-Version: 1.0 References: <155440490809.3190322.15060922240602775809.stgit@dwillia2-desk3.amr.corp.intel.com> <155440492988.3190322.4475460421334178449.stgit@dwillia2-desk3.amr.corp.intel.com> <20190405121857.0000718a@huawei.com> In-Reply-To: <20190405121857.0000718a@huawei.com> From: Dan Williams Date: Fri, 5 Apr 2019 08:43:03 -0700 Message-ID: Subject: Re: [RFC PATCH 4/5] acpi/hmat: Register special purpose memory as a device To: Jonathan Cameron Cc: Linux Kernel Mailing List , "Rafael J. Wysocki" , Len Brown , Keith Busch , Vishal L Verma , X86 ML , Linux MM , linux-nvdimm Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 5, 2019 at 4:19 AM Jonathan Cameron wrote: > > On Thu, 4 Apr 2019 12:08:49 -0700 > Dan Williams wrote: > > > Memory that has been tagged EFI_SPECIAL_PURPOSE, and has performance > > properties described by the ACPI HMAT is expected to have an application > > specific consumer. > > > > Those consumers may want 100% of the memory capacity to be reserved from > > any usage by the kernel. By default, with this enabling, a platform > > device is created to represent this differentiated resource. > > > > A follow on change arranges for device-dax to claim these devices by > > default and provide an mmap interface for the target application. > > However, if the administrator prefers that some or all of the special > > purpose memory is made available to the core-mm the device-dax hotplug > > facility can be used to online the memory with its own numa node. > > > > Cc: "Rafael J. Wysocki" > > Cc: Len Brown > > Cc: Keith Busch > > Cc: Jonathan Cameron > > Signed-off-by: Dan Williams > > Hi Dan, > > Great to see you getting this discussion going so fast and in > general the approach makes sense to me. > > I'm a little confused why HMAT has anything to do with this. > SPM is defined either via the attribute in SRAT SPA entries, > EF_MEMORY_SP or via the EFI memory map. > > Whether it is in HMAT or not isn't all that relevant. > Back in the days of the reservation hint (so before yesterday :) > it was relevant obviously but that's no longer true. > > So what am I missing? It's a good question, and an assumption I should have explicitly declared in the changelog. The problem with EFI_MEMORY_SP is the same as the problem with the EfiPersistentMemory type, it isn't precise enough on its own for the kernel to delineate 'type' or device/replaceable-unit boundaries. For example, I expect one EFI_MEMORY_SP range of a specific type may be contiguous with another range of a different type. Similar to the NFIT there is no requirement in the specification that platform firmware inject multiple range entries. Instead that precision is left to the SRAT + HMAT, or the NFIT in the case of PMEM. Conversely, and thinking through this a bit more, if a memory range is "special", but the platform fails to enumerate it in HMAT I think Linux should scream loudly that the firmware is broken and leave the range alone. The "scream loudly" piece is missing in the current set, but the "leave the range alone" functionality is included.