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=-3.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 B53DFC433E4 for ; Fri, 21 Aug 2020 21:34:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8B8B020724 for ; Fri, 21 Aug 2020 21:34:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="KnoT3IMc" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726670AbgHUVeE (ORCPT ); Fri, 21 Aug 2020 17:34:04 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:54524 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725948AbgHUVeD (ORCPT ); Fri, 21 Aug 2020 17:34:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1598045641; h=from:from: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=vgmuzKXgcjBcRgoPDChBvhGV7hX/eWB5I9mkSmfnUJ8=; b=KnoT3IMcqqB3fswvdvNI0yveXrZokUuSzdgmZ4/JTzpdXpC7GZr/biPAfajcoR3wmk10gi ItH0bmcF+mXmhCSkg88kPg31t7gMPYyS7L0onId4iOinkHK1J4eSvWrQCcuHd4zqj+wJWG /1Xiv+9Ig0k2COdCZmvu447BriBkDvs= Received: from mail-ej1-f70.google.com (mail-ej1-f70.google.com [209.85.218.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-229-U4CsQeWmMn2wIlKqUcRYIg-1; Fri, 21 Aug 2020 17:34:00 -0400 X-MC-Unique: U4CsQeWmMn2wIlKqUcRYIg-1 Received: by mail-ej1-f70.google.com with SMTP id lg2so1229592ejb.23 for ; Fri, 21 Aug 2020 14:33:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=vgmuzKXgcjBcRgoPDChBvhGV7hX/eWB5I9mkSmfnUJ8=; b=I/Ee0TjGxnX1iCR3iZPSNNwgqwLvaPK4QF6Z6JIYOmprH0ikZj4jyYjVVwNDzYsOs1 KRUMqd/j9YMlpguYUTkypco0zvWlkqh+g+hkG0DyYAYw2uWtHD8w4qyJysblT0gMMpLq xE8RwShPRkf536ZdqCsuI819ves3rEm05vLxpgrhk4c27N0a4675DdPRCbX9HvDOHztJ d2e1G4RMDC1GpWiI92brYg8SAs8bm7kwB7QkZYm/+DzyTXQq4nOxM2B4K8DyNg3jYVQo UdXF8cIu0Zvb4kUCj9tbFsogcycmRKHU6J43eCZiDXb3nnUXzT0RC29AzvxFtdk33h8s a4Ww== X-Gm-Message-State: AOAM532JJiFIvneIUmlOuFyBwxeQX/LoH/4XnytVFaPMtozpWJcNR5jM JxMjB8EoMQROkmi753b5KzajbM02xihxEzvBt5nrnRMCbW7mTTJWTIoyVc4fWL5Z1yUsqDHIgJU G163iHaQman6RjsQr6a8gSQ== X-Received: by 2002:aa7:db10:: with SMTP id t16mr4670970eds.196.1598045639009; Fri, 21 Aug 2020 14:33:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzsY3HWTjNmnI8n64swZ39edXjTL651Y7phqEaxt8pR/mpnMiF2k94JkzZc4axtZWxBWkdbNw== X-Received: by 2002:aa7:db10:: with SMTP id t16mr4670942eds.196.1598045638810; Fri, 21 Aug 2020 14:33:58 -0700 (PDT) Received: from [192.168.3.122] (p5b0c6231.dip0.t-ipconnect.de. [91.12.98.49]) by smtp.gmail.com with ESMTPSA id j21sm93193eja.109.2020.08.21.14.33.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 21 Aug 2020 14:33:58 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: David Hildenbrand Mime-Version: 1.0 (1.0) Subject: Re: [PATCH v4 00/23] device-dax: Support sub-dividing soft-reserved ranges Date: Fri, 21 Aug 2020 23:33:57 +0200 Message-Id: <646DDE9B-90C2-493A-958C-90EFA1CCA475@redhat.com> References: Cc: David Hildenbrand , Andrew Morton , Ira Weiny , Ard Biesheuvel , Mike Rapoport , Borislav Petkov , Vishal Verma , David Airlie , Will Deacon , Catalin Marinas , Ard Biesheuvel , Joao Martins , Tom Lendacky , Dave Jiang , "Rafael J. Wysocki" , Jonathan Cameron , Wei Yang , X86 ML , "H. Peter Anvin" , Thomas Gleixner , Greg Kroah-Hartman , Pavel Tatashin , Peter Zijlstra , Ben Skeggs , Benjamin Herrenschmidt , Jason Gunthorpe , Jia He , Ingo Molnar , Dave Hansen , Paul Mackerras , Brice Goglin , Jeff Moyer , Michael Ellerman , "Rafael J. Wysocki" , Daniel Vetter , Andy Lutomirski , "Rafael J. Wysocki" , Linux MM , linux-nvdimm , Linux Kernel Mailing List , Linux ACPI , Maling list - DRI developers In-Reply-To: To: Dan Williams X-Mailer: iPhone Mail (17G68) Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org > Am 21.08.2020 um 23:17 schrieb Dan Williams : >=20 > =EF=BB=BFOn Fri, Aug 21, 2020 at 11:30 AM David Hildenbrand wrote: >>=20 >>> On 21.08.20 20:27, Dan Williams wrote: >>> On Fri, Aug 21, 2020 at 3:15 AM David Hildenbrand wro= te: >>>>=20 >>>>>>=20 >>>>>> 1. On x86-64, e820 indicates "soft-reserved" memory. This memory is n= ot >>>>>> automatically used in the buddy during boot, but remains untouched >>>>>> (similar to pmem). But as it involves ACPI as well, it could also be >>>>>> used on arm64 (-e820), correct? >>>>>=20 >>>>> Correct, arm64 also gets the EFI support for enumerating memory this >>>>> way. However, I would clarify that whether soft-reserved is given to >>>>> the buddy allocator by default or not is the kernel's policy choice, >>>>> "buddy-by-default" is ok and is what will happen anyways with older >>>>> kernels on platforms that enumerate a memory range this way. >>>>=20 >>>> Is "soft-reserved" then the right terminology for that? It sounds very >>>> x86-64/e820 specific. Maybe a compressed for of "performance >>>> differentiated memory" might be a better fit to expose to user space, n= o? >>>=20 >>> No. The EFI "Specific Purpose" bit is an attribute independent of >>> e820, it's x86-Linux that entangles those together. There is no >>> requirement for platform firmware to use that designation even for >>> drastic performance differentiation between ranges, and conversely >>> there is no requirement that memory *with* that designation has any >>> performance difference compared to the default memory pool. So it >>> really is a reservation policy about a memory range to keep out of the >>> buddy allocator by default. >>=20 >> Okay, still "soft-reserved" is x86-64 specific, no? >=20 > There's nothing preventing other EFI archs, or a similar designation > in another firmware spec, picking up this policy. >=20 >> (AFAIK, >> "soft-reserved" will be visible in /proc/iomem, or am I confusing >> stuff?) >=20 > No, you're correct. >=20 >> IOW, it "performance differentiated" is not universally >> applicable, maybe "specific purpose memory" is ? >=20 > Those bikeshed colors don't seem an improvement to me. >=20 > "Soft-reserved" actually tells you something about the kernel policy > for the memory. The criticism of "specific purpose" that led to > calling it "soft-reserved" in Linux is the fact that "specific" is > undefined as far as the firmware knows, and "specific" may have > different applications based on the platform user. "Soft-reserved" > like "Reserved" tells you that a driver policy might be in play for > that memory. >=20 > Also note that the current color of the bikeshed has already shipped since= v5.5: >=20 > 262b45ae3ab4 x86/efi: EFI soft reservation to E820 enumeration >=20 I was asking because I was struggling to even understand what =E2=80=9Esoft-= reserved=E2=80=9C is and I could bet most people have no clue what that is s= upposed to be. In contrast =E2=80=9Epersistent memory=E2=80=9C or =E2=80=9Especial purpose m= emory=E2=80=9C in /proc/iomem is something normal (Linux using) human beings= can understand. But anyhow, just details, and you=E2=80=98re telling me that that ship alrea= dy sailed. So no further comments from my side. Thanks for all the info!=