1. 09 3月, 2021 1 次提交
    • A
      arm64/mm: Fix pfn_valid() for ZONE_DEVICE based memory · eeb0753b
      Anshuman Khandual 提交于
      pfn_valid() validates a pfn but basically it checks for a valid struct page
      backing for that pfn. It should always return positive for memory ranges
      backed with struct page mapping. But currently pfn_valid() fails for all
      ZONE_DEVICE based memory types even though they have struct page mapping.
      
      pfn_valid() asserts that there is a memblock entry for a given pfn without
      MEMBLOCK_NOMAP flag being set. The problem with ZONE_DEVICE based memory is
      that they do not have memblock entries. Hence memblock_is_map_memory() will
      invariably fail via memblock_search() for a ZONE_DEVICE based address. This
      eventually fails pfn_valid() which is wrong. memblock_is_map_memory() needs
      to be skipped for such memory ranges. As ZONE_DEVICE memory gets hotplugged
      into the system via memremap_pages() called from a driver, their respective
      memory sections will not have SECTION_IS_EARLY set.
      
      Normal hotplug memory will never have MEMBLOCK_NOMAP set in their memblock
      regions. Because the flag MEMBLOCK_NOMAP was specifically designed and set
      for firmware reserved memory regions. memblock_is_map_memory() can just be
      skipped as its always going to be positive and that will be an optimization
      for the normal hotplug memory. Like ZONE_DEVICE based memory, all normal
      hotplugged memory too will not have SECTION_IS_EARLY set for their sections
      
      Skipping memblock_is_map_memory() for all non early memory sections would
      fix pfn_valid() problem for ZONE_DEVICE based memory and also improve its
      performance for normal hotplug memory as well.
      
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will@kernel.org>
      Cc: Ard Biesheuvel <ardb@kernel.org>
      Cc: Robin Murphy <robin.murphy@arm.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-kernel@vger.kernel.org
      Acked-by: NDavid Hildenbrand <david@redhat.com>
      Fixes: 73b20c84 ("arm64: mm: implement pte_devmap support")
      Signed-off-by: NAnshuman Khandual <anshuman.khandual@arm.com>
      Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
      Link: https://lore.kernel.org/r/1614921898-4099-2-git-send-email-anshuman.khandual@arm.comSigned-off-by: NWill Deacon <will@kernel.org>
      eeb0753b
  2. 08 3月, 2021 4 次提交
    • A
      arm64/mm: Drop THP conditionality from FORCE_MAX_ZONEORDER · 79cc2ed5
      Anshuman Khandual 提交于
      Currently without THP being enabled, MAX_ORDER via FORCE_MAX_ZONEORDER gets
      reduced to 11, which falls below HUGETLB_PAGE_ORDER for certain 16K and 64K
      page size configurations. This is problematic which throws up the following
      warning during boot as pageblock_order via HUGETLB_PAGE_ORDER order exceeds
      MAX_ORDER.
      
      WARNING: CPU: 7 PID: 127 at mm/vmstat.c:1092 __fragmentation_index+0x58/0x70
      Modules linked in:
      CPU: 7 PID: 127 Comm: kswapd0 Not tainted 5.12.0-rc1-00005-g0221e3101a1 #237
      Hardware name: linux,dummy-virt (DT)
      pstate: 20400005 (nzCv daif +PAN -UAO -TCO BTYPE=--)
      pc : __fragmentation_index+0x58/0x70
      lr : fragmentation_index+0x88/0xa8
      sp : ffff800016ccfc00
      x29: ffff800016ccfc00 x28: 0000000000000000
      x27: ffff800011fd4000 x26: 0000000000000002
      x25: ffff800016ccfda0 x24: 0000000000000002
      x23: 0000000000000640 x22: ffff0005ffcb5b18
      x21: 0000000000000002 x20: 000000000000000d
      x19: ffff0005ffcb3980 x18: 0000000000000004
      x17: 0000000000000001 x16: 0000000000000019
      x15: ffff800011ca7fb8 x14: 00000000000002b3
      x13: 0000000000000000 x12: 00000000000005e0
      x11: 0000000000000003 x10: 0000000000000080
      x9 : ffff800011c93948 x8 : 0000000000000000
      x7 : 0000000000000000 x6 : 0000000000007000
      x5 : 0000000000007944 x4 : 0000000000000032
      x3 : 000000000000001c x2 : 000000000000000b
      x1 : ffff800016ccfc10 x0 : 000000000000000d
      Call trace:
      __fragmentation_index+0x58/0x70
      compaction_suitable+0x58/0x78
      wakeup_kcompactd+0x8c/0xd8
      balance_pgdat+0x570/0x5d0
      kswapd+0x1e0/0x388
      kthread+0x154/0x158
      ret_from_fork+0x10/0x30
      
      This solves the problem via keeping FORCE_MAX_ZONEORDER unchanged with or
      without THP on 16K and 64K page size configurations, making sure that the
      HUGETLB_PAGE_ORDER (and pageblock_order) would never exceed MAX_ORDER.
      
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will@kernel.org>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NAnshuman Khandual <anshuman.khandual@arm.com>
      Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
      Link: https://lore.kernel.org/r/1614597914-28565-1-git-send-email-anshuman.khandual@arm.comSigned-off-by: NWill Deacon <will@kernel.org>
      79cc2ed5
    • A
      arm64/mm: Drop redundant ARCH_WANT_HUGE_PMD_SHARE · 07fb6dc3
      Anshuman Khandual 提交于
      There is already an ARCH_WANT_HUGE_PMD_SHARE which is being selected for
      applicable configurations. Hence just drop the other redundant entry.
      
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will@kernel.org>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NAnshuman Khandual <anshuman.khandual@arm.com>
      Link: https://lore.kernel.org/r/1614575192-21307-1-git-send-email-anshuman.khandual@arm.comSigned-off-by: NWill Deacon <will@kernel.org>
      07fb6dc3
    • W
      arm64: Drop support for CMDLINE_EXTEND · cae118b6
      Will Deacon 提交于
      The documented behaviour for CMDLINE_EXTEND is that the arguments from
      the bootloader are appended to the built-in kernel command line. This
      also matches the option parsing behaviour for the EFI stub and early ID
      register overrides.
      
      Bizarrely, the fdt behaviour is the other way around: appending the
      built-in command line to the bootloader arguments, resulting in a
      command-line that doesn't necessarily line-up with the parsing order and
      definitely doesn't line-up with the documented behaviour.
      
      As it turns out, there is a proposal [1] to replace CMDLINE_EXTEND with
      CMDLINE_PREPEND and CMDLINE_APPEND options which should hopefully make
      the intended behaviour much clearer. While we wait for those to land,
      drop CMDLINE_EXTEND for now as there appears to be little enthusiasm for
      changing the current FDT behaviour.
      
      [1] https://lore.kernel.org/lkml/20190319232448.45964-2-danielwa@cisco.com/
      
      Cc: Max Uvarov <muvarov@gmail.com>
      Cc: Rob Herring <robh@kernel.org>
      Cc: Ard Biesheuvel <ardb@kernel.org>
      Cc: Marc Zyngier <maz@kernel.org>
      Cc: Doug Anderson <dianders@chromium.org>
      Cc: Tyler Hicks <tyhicks@linux.microsoft.com>
      Cc: Frank Rowand <frowand.list@gmail.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Link: https://lore.kernel.org/r/CAL_JsqJX=TCCs7=gg486r9TN4NYscMTCLNfqJF9crskKPq-bTg@mail.gmail.com
      Link: https://lore.kernel.org/r/20210303134927.18975-3-will@kernel.orgSigned-off-by: NWill Deacon <will@kernel.org>
      cae118b6
    • W
      arm64: cpufeatures: Fix handling of CONFIG_CMDLINE for idreg overrides · df304c2d
      Will Deacon 提交于
      The built-in kernel commandline (CONFIG_CMDLINE) can be configured in
      three different ways:
      
        1. CMDLINE_FORCE: Use CONFIG_CMDLINE instead of any bootloader args
        2. CMDLINE_EXTEND: Append the bootloader args to CONFIG_CMDLINE
        3. CMDLINE_FROM_BOOTLOADER: Only use CONFIG_CMDLINE if there aren't
           any bootloader args.
      
      The early cmdline parsing to detect idreg overrides gets (2) and (3)
      slightly wrong: in the case of (2) the bootloader args are parsed first
      and in the case of (3) the CMDLINE is always parsed.
      
      Fix these issues by moving the bootargs parsing out into a helper
      function and following the same logic as that used by the EFI stub.
      Reviewed-by: NMarc Zyngier <maz@kernel.org>
      Fixes: 33200303 ("arm64: cpufeature: Add an early command-line cpufeature override facility")
      Link: https://lore.kernel.org/r/20210303134927.18975-2-will@kernel.orgSigned-off-by: NWill Deacon <will@kernel.org>
      df304c2d
  3. 03 3月, 2021 7 次提交
  4. 28 2月, 2021 1 次提交
  5. 27 2月, 2021 20 次提交
  6. 26 2月, 2021 5 次提交
  7. 25 2月, 2021 2 次提交