From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 3319B8213A for ; Fri, 24 Feb 2017 15:18:36 -0800 (PST) Received: by mail-it0-x22c.google.com with SMTP id h10so33674657ith.1 for ; Fri, 24 Feb 2017 15:18:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=21+NTBjFjXAmU6/p7mwvc036zeOXnCRisiu/4HgLDe0=; b=cI31JX0z/PLELEj2VUH0WJq4OJDoGjaAFfs//zJ/U/NQxTc1guiAC/T7092t/KwvJ7 gQfak33qRl7bVyLEh1rC0DRfplgZIgdq0XXFcWcdX+3YMks1VTEVH/pZLTBrCeGW9a+v V5bhp6sA3kZnCFzAnd1SOkFTWCE5Al0AChu8E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=21+NTBjFjXAmU6/p7mwvc036zeOXnCRisiu/4HgLDe0=; b=plQR5tTDk42ebBaWUioQD9fZygmxSH407j0yFNpYJ36hYkHnlXaWlyg58tj293SbpY nUApyUR2eUIALp7Txz2Urpl8Y6L/B4YKFzw8OzgflHPN3cdPl0ReJ/OoAvvVqPPZO98x DgaJ2r8HFxP2/5kKBt4R2jte9aoq8gQA8mbbmHN/r6wBh8OdBtfnGmuGOivJADn5qpub EkO1pOvuFBE8wyJpjBFNgg9RedVn3pbabnirmQZpWsD8K/3j/fWicOtHp3R2sSrrm80u 2sLSYjEtJsZ6aXZrdyTA3O0FlM4IEtGIs0MuPfU7Fnwxr/f9JIicBiX149SzL+owRwvm mF+Q== X-Gm-Message-State: AMke39k2jP3tebcdZh6U2onT6YDn/y8OOBHUBt2Nb/8MwOu1uFx3E+fSAwtJV8YKTxyP0Od1bbWigy3SBcuhN9vl X-Received: by 10.36.207.212 with SMTP id y203mr4604551itf.63.1487978315492; Fri, 24 Feb 2017 15:18:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.198.134 with HTTP; Fri, 24 Feb 2017 15:18:34 -0800 (PST) In-Reply-To: <7c091253-af00-176d-c796-d6120d4fc2a9@redhat.com> References: <1487960215-14052-1-git-send-email-ard.biesheuvel@linaro.org> <7c091253-af00-176d-c796-d6120d4fc2a9@redhat.com> From: Ard Biesheuvel Date: Fri, 24 Feb 2017 23:18:34 +0000 Message-ID: To: Laszlo Ersek Cc: "edk2-devel@lists.01.org" , Leif Lindholm Subject: Re: [PATCH] ArmVirtPkg: clear PcdPerformanceLibraryPropertyMask PCD X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 23:18:36 -0000 Content-Type: text/plain; charset=UTF-8 On 24 February 2017 at 23:17, Laszlo Ersek wrote: > On 02/24/17 19:16, Ard Biesheuvel wrote: >> The only observeable effect of having PcdPerformanceLibraryPropertyMask >> set to 1 is that a EfiReservedMemory region of 4 pages is allocated right >> below the 4 GB mark. This region is out of bounds for the OS, which means >> it is not even allowed to map it, to avoid speculative loads from it. >> >> On Linux, this may prevent the kernel from using a 1 GB block mappings for >> this region, and instead it has to carve up the block as follows: >> >> 0xffffffff80000000-0xffffffffbe000000 992M PMD CON BLK >> 0xffffffffbe000000-0xffffffffbfe00000 30M PMD BLK >> 0xffffffffbfe00000-0xffffffffbfff0000 1984K PTE CON >> 0xffffffffbfff0000-0xffffffffbfffc000 48K PTE >> >> where it would otherwise use a single 1 GB mapping (*), i.e., >> >> 0xffffffff80000000-0xffffffffc0000000 1G PGD >> >> To clarify, the latter is a single 8 byte entry in the top level page >> table, whereas in the former case, we have two additional levels of >> paging, requiring two extra 4 KB pages (on a 4 KB pagesize kernel). >> >> The real cost, however, is the TLB footprint, which goes up from a >> single entry to a value between 90 and 1020, depending on whether >> contiguous hints are honoured by the hardware. >> >> So let's set PcdPerformanceLibraryPropertyMask to zero until we find >> a reason why we shouldn't. >> >> (*) provided that no other allocations were deliberately located right >> below the 4 GB mark, and that we are running with more than 3 GB of >> memory, in which case most allocations will be over 4 GB, given EDK2's >> default top-down allocation policy. >> >> Contributed-under: TianoCore Contribution Agreement 1.0 >> Signed-off-by: Ard Biesheuvel >> --- >> ArmVirtPkg/ArmVirt.dsc.inc | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc >> index 61d4a6642eb7..ca0a4d31a03d 100644 >> --- a/ArmVirtPkg/ArmVirt.dsc.inc >> +++ b/ArmVirtPkg/ArmVirt.dsc.inc >> @@ -295,7 +295,7 @@ [PcdsFixedAtBuild.common] >> gEfiMdePkgTokenSpaceGuid.PcdMaximumLinkedListLength|1000000 >> gEfiMdePkgTokenSpaceGuid.PcdSpinLockTimeout|10000000 >> gEfiMdePkgTokenSpaceGuid.PcdDebugClearMemoryValue|0xAF >> - gEfiMdePkgTokenSpaceGuid.PcdPerformanceLibraryPropertyMask|1 >> + gEfiMdePkgTokenSpaceGuid.PcdPerformanceLibraryPropertyMask|0 >> gEfiMdePkgTokenSpaceGuid.PcdPostCodePropertyMask|0 >> gEfiMdePkgTokenSpaceGuid.PcdUefiLibMaxPrintBufferSize|320 >> >> > > The value 1 dates back to ancient commit 6f5872b1f401 ("ArmPlatformPkg/ArmVirtualizationPkg: Add ArmVirtualizationQemu platform", 2014-09-18). > > The default is zero in "MdePkg/MdePkg.dec": > > ## The mask is used to control PerformanceLib behavior.

> # BIT0 - Enable Performance Measurement.
> # @Prompt Performance Measurement Property. > # @Expression 0x80000002 | (gEfiMdePkgTokenSpaceGuid.PcdPerformanceLibraryPropertyMask & 0xFE) == 0 > gEfiMdePkgTokenSpaceGuid.PcdPerformanceLibraryPropertyMask|0|UINT8|0x00000009 > > Shouldn't we just remove the line? > Sure, even better!