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 3C6CFC433E1 for ; Fri, 21 Aug 2020 22:07:51 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EC0C3208DB for ; Fri, 21 Aug 2020 22:07:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="Uy/SiJQI" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EC0C3208DB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 70E5E6B0010; Fri, 21 Aug 2020 18:07:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6E6528D008A; Fri, 21 Aug 2020 18:07:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5D5558D0089; Fri, 21 Aug 2020 18:07:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 476356B0010 for ; Fri, 21 Aug 2020 18:07:50 -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 0C6298248068 for ; Fri, 21 Aug 2020 22:07:50 +0000 (UTC) X-FDA: 77175963900.24.glass80_2716b132703c Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin24.hostedemail.com (Postfix) with ESMTP id D8D6F1A4A0 for ; Fri, 21 Aug 2020 22:07:49 +0000 (UTC) X-HE-Tag: glass80_2716b132703c X-Filterd-Recvd-Size: 8566 Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by imf28.hostedemail.com (Postfix) with ESMTP for ; Fri, 21 Aug 2020 22:07:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1598047668; 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=XjtI18d1f2H/aKTyFHmileH6IrtXVHmAbfK2HkX3dk0=; b=Uy/SiJQITj/pyvkIfObllrS3fB4/X87vzIgDdfX5Fv4vxDw6Kg6yNBhOgM2pZ0VmxsQKRC eARQAW9/jRciEcAwEaPHyvw1tjeSKZtZ+ebh0k7gp52RzNCk41ajIBEj4sHCpIJDOLshtk VxCVXfeNOYzeWdCjKTzBpKagQ6kRkTk= Received: from mail-ej1-f69.google.com (mail-ej1-f69.google.com [209.85.218.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-339-8N1zsazqOxmrj-3MohO4aA-1; Fri, 21 Aug 2020 18:07:46 -0400 X-MC-Unique: 8N1zsazqOxmrj-3MohO4aA-1 Received: by mail-ej1-f69.google.com with SMTP id i4so1280817ejk.9 for ; Fri, 21 Aug 2020 15:07:46 -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=6/wi0Nw+OScWqjXUa7deT7et3gd07Go77zu0NJl9auw=; b=J5atFgTHAzLxH+BQtE+LolCFQz8coTpGMCmzcvLjbwPdV5OMB9WYn/FkDZ8/VRMqXW ER8Hr0vX5myCZZjN+g1KY2nV2gKBbSqo4uuVDrwSX4/yhToUzO3wgRWfauK9Ja53a8oG mksFPsK//WVxB2iUCjqsEJBxvxymjRWnBCGKOnm1VWIqUVS5gS9EmBPfPl6/RRL6ImmF ebCbOLrFCUUAIHybKgpcm7fcLYbaLnduJyGPM+Dt/BsakguZ2DV4c6eiNu5DvU+YIaHs kdkWeHR9QYw7sR4FV/oACRvhLARmSA/HqFZVrhwp+++GR9hpTcyx6+p2P9KgMvCvVaIo Bhvg== X-Gm-Message-State: AOAM5323TQgg1knM0NCFLXGVQgmzSZDofrGfNZN0aGIuEOYi0FsGU3zA 6DgNSUaCip8fOG6l52ZGn1Yc/BfG3yEnw0jBuKC1qToVCzCN8+dbzA1ihJ92jE6UkSHhCW/V2/X 9CAUyQCfTddk= X-Received: by 2002:a17:906:6d91:: with SMTP id h17mr4593030ejt.531.1598047665747; Fri, 21 Aug 2020 15:07:45 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz2fGCDlUrSC0ozVrUImslz75nvdXz6gshUl15sF6TxX4V9+R9BHsd6i/JypP0Cf8+w6d3+oA== X-Received: by 2002:a17:906:6d91:: with SMTP id h17mr4593016ejt.531.1598047665540; Fri, 21 Aug 2020 15:07:45 -0700 (PDT) Received: from [192.168.3.122] (p5b0c6231.dip0.t-ipconnect.de. [91.12.98.49]) by smtp.gmail.com with ESMTPSA id n10sm1810467edo.43.2020.08.21.15.07.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 21 Aug 2020 15:07:45 -0700 (PDT) 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:42:49 +0200 Message-Id: <1FB395E7-633D-4F3E-82F5-12E2FDAF33EC@redhat.com> References: <646DDE9B-90C2-493A-958C-90EFA1CCA475@redhat.com> 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 In-Reply-To: <646DDE9B-90C2-493A-958C-90EFA1CCA475@redhat.com> To: Dan Williams X-Mailer: iPhone Mail (17G68) Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=david@redhat.com X-Mimecast-Spam-Score: 0.502 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: D8D6F1A4A0 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam01 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: > Am 21.08.2020 um 23:34 schrieb David Hildenbrand : >=20 > =EF=BB=BF >=20 >>> 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 w= rote: >>>>>=20 >>>>>>>=20 >>>>>>> 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 b= e >>>>>>> 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 ver= y >>>>> x86-64/e820 specific. Maybe a compressed for of "performance >>>>> differentiated memory" might be a better fit to expose to user space,= no? >>>>=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 sin= ce v5.5: >>=20 >> 262b45ae3ab4 x86/efi: EFI soft reservation to E820 enumeration >>=20 >=20 > I was asking because I was struggling to even understand what =E2=80=9Eso= ft-reserved=E2=80=9C is and I could bet most people have no clue what that = is supposed to be. >=20 > In contrast =E2=80=9Epersistent memory=E2=80=9C or =E2=80=9Especial purpo= se memory=E2=80=9C in /proc/iomem is something normal (Linux using) human b= eings can understand. s/normal/most/ of course :)