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.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 9BDD1C433E3 for ; Fri, 21 Aug 2020 21:17:32 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5C41020791 for ; Fri, 21 Aug 2020 21:17:32 +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="GXn5QvE0" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5C41020791 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id DAF248D0085; Fri, 21 Aug 2020 17:17:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D61428D0002; Fri, 21 Aug 2020 17:17:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C4E8A8D0085; Fri, 21 Aug 2020 17:17:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id AB9DD8D0002 for ; Fri, 21 Aug 2020 17:17:31 -0400 (EDT) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 6868B8245571 for ; Fri, 21 Aug 2020 21:17:31 +0000 (UTC) X-FDA: 77175837102.24.pot45_5c042bd2703c Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin24.hostedemail.com (Postfix) with ESMTP id 3F6CB10F8C for ; Fri, 21 Aug 2020 21:17:31 +0000 (UTC) X-HE-Tag: pot45_5c042bd2703c X-Filterd-Recvd-Size: 7230 Received: from mail-ej1-f67.google.com (mail-ej1-f67.google.com [209.85.218.67]) by imf04.hostedemail.com (Postfix) with ESMTP for ; Fri, 21 Aug 2020 21:17:30 +0000 (UTC) Received: by mail-ej1-f67.google.com with SMTP id m22so4044999eje.10 for ; Fri, 21 Aug 2020 14:17:30 -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=Czkv47Mapytq1xHY+oPYH574MMmQySGYRJkgBW3lM+E=; b=GXn5QvE0B4fW4XfVmy6nF7VEmR25ramQstv7uYApzkRaODFrVdOXnM1zTZ6Wsmibwy dPfmTNTs899e7OIe+phFR2chos0Ft2tgG9zqM01uVVZPmE29arGNgsIzosvPzhSWUnGe J3wNyPfrnyhgIVWAU45//p0AhY4mBc6FUmzeNpTdQDSCbuWVi6ai4sl/4TKN7Bd6ypw8 5lZeOIWb5H2+OaFKo947ypFBddehhnskfMBHe4gMQN+LdPUupi+433hVBX7NeDX/oBC5 TgSqJ5flLj3v0348Ps+2DpHLbXs1TxDkDp2CaVgcTvVCd7lwN8q+51xsM4whGP0VMhL1 x6yQ== 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=Czkv47Mapytq1xHY+oPYH574MMmQySGYRJkgBW3lM+E=; b=ffYi/d71S+ASpfamL8Ug8J+JUBfZXJ7ig5ebAEw3LqernSC7BETE5DgowGRO0JaLVs z5Pq1+obIqQV6rqUtpIsb+gpjZI6molGwYRdUekpem+rCwHkrMuBDymjkhJ46xDKFChB Kg1pMwGjYwsgbH3aWMhg140bz8lbzBEgEFLUTkqLgl6x4uNeMx24BB7oq5ZcRB1Gltpt AEM0a29xxTm3O0Ejf+Twfm90igQQcdx57S9aBaYkBkrVuX9yAc+Hc+3GgcessQScnhFQ dCN0XJOygTWb0wnqjKsi5+dyhQ8E5ngF71EZiXux84B69jfCQHoHtDdrDsi7sProNVNR u02w== X-Gm-Message-State: AOAM533kngsW5LH466P7i3YRzTzvdcUfyFKkzf8TBGBBYpflpm5sopWy xRrSDrKeEnGWvM+oO0kxbnlsJv9BAG+ZRgCUYOQZag== X-Google-Smtp-Source: ABdhPJw7R+XywZgNxGuYeGtmKWkV2KF0ClltQZXGVP6GBaNPhi5e1DOir94iWrkYJw3POQerQKgrC5Sthl/6YvvLxa0= X-Received: by 2002:a17:907:10d9:: with SMTP id rv25mr4570332ejb.264.1598044649266; Fri, 21 Aug 2020 14:17:29 -0700 (PDT) MIME-Version: 1.0 References: <159643094279.4062302.17779410714418721328.stgit@dwillia2-desk3.amr.corp.intel.com> <6af3de0d-ffdc-8942-3922-ebaeef20dd63@redhat.com> <3dfde5e3-e1e2-2097-afa1-303042de5e07@redhat.com> In-Reply-To: <3dfde5e3-e1e2-2097-afa1-303042de5e07@redhat.com> From: Dan Williams Date: Fri, 21 Aug 2020 14:17:18 -0700 Message-ID: Subject: Re: [PATCH v4 00/23] device-dax: Support sub-dividing soft-reserved ranges To: David Hildenbrand Cc: 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 Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 3F6CB10F8C X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Aug 21, 2020 at 11:30 AM David Hildenbrand wrote: > > On 21.08.20 20:27, Dan Williams wrote: > > On Fri, Aug 21, 2020 at 3:15 AM David Hildenbrand wrote: > >> > >>>> > >>>> 1. On x86-64, e820 indicates "soft-reserved" memory. This memory is not > >>>> 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? > >>> > >>> 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. > >> > >> 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, no? > > > > 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. > > Okay, still "soft-reserved" is x86-64 specific, no? There's nothing preventing other EFI archs, or a similar designation in another firmware spec, picking up this policy. > (AFAIK, > "soft-reserved" will be visible in /proc/iomem, or am I confusing > stuff?) No, you're correct. > IOW, it "performance differentiated" is not universally > applicable, maybe "specific purpose memory" is ? Those bikeshed colors don't seem an improvement to me. "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. Also note that the current color of the bikeshed has already shipped since v5.5: 262b45ae3ab4 x86/efi: EFI soft reservation to E820 enumeration