From: Mike Rapoport <rppt@kernel.org>
To: x86@kernel.org
Cc: Andy Lutomirski <luto@kernel.org>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
Mike Rapoport <rppt@kernel.org>,
Mike Rapoport <rppt@linux.ibm.com>,
Peter Zijlstra <peterz@infradead.org>,
Rick Edgecombe <rick.p.edgecombe@intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
linux-kernel@vger.kernel.org
Subject: [PATCH 0/4] x86/mm: replace GFP_ATOMIC with GFP_KERNEL for direct map allocations
Date: Thu, 11 Nov 2021 13:02:37 +0200 [thread overview]
Message-ID: <20211111110241.25968-1-rppt@kernel.org> (raw)
From: Mike Rapoport <rppt@linux.ibm.com>
Hi,
The direct map pages on x86 that are allocated using alloc_low_pages() and
spp_getpage() functions. When these functions take 'after_bootmem' branch,
the memory is allocated from buddy with GFP_ATOMIC and I could not find any
reason for this.
Since most of the kernel page tables are anyway allocated really early,
only GART IOMMU initialization and memory hotplug would actually use
get_free_pages() to allocate direct map entries and neither of them happen
in an atomic context, so it would be fine to use GFP_KERNEL. This will give
the page allocator more flexibility when memory hotplug creates the direct
map for hot-added memory and won't use precious atomic memory resources.
The first three patches are trivial cleanups I've encountered while
analysing call paths of alloc_low_pages() and spp_getpage() and the fourth
patch actually replaces GFP_ATOMIC with GFP_KERNEL in those functions.
Mike Rapoport (4):
x86/mm: make init_trampoline_kaslr() __init
x86/mm: make kernel_physical_mapping_change() __init
x86/mm: init_64: make set_pte_vaddr_p4d static
x86/mm: replace GFP_ATOMIC with GFP_KERNEL for direct map allocations
arch/x86/include/asm/pgtable_64.h | 1 -
arch/x86/mm/init.c | 2 +-
arch/x86/mm/init_64.c | 7 ++++---
arch/x86/mm/kaslr.c | 2 +-
4 files changed, 6 insertions(+), 6 deletions(-)
base-commit: d2f38a3c6507b2520101f9a3807ed98f1bdc545a
--
2.28.0
next reply other threads:[~2021-11-11 11:02 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-11 11:02 Mike Rapoport [this message]
2021-11-11 11:02 ` [PATCH 1/4] x86/mm: make init_trampoline_kaslr() __init Mike Rapoport
2021-11-11 20:46 ` Edgecombe, Rick P
2021-11-11 11:02 ` [PATCH 2/4] x86/mm: make kernel_physical_mapping_change() __init Mike Rapoport
2021-11-11 20:47 ` Edgecombe, Rick P
2021-11-11 11:02 ` [PATCH 3/4] x86/mm: init_64: make set_pte_vaddr_p4d static Mike Rapoport
2021-11-11 20:48 ` Edgecombe, Rick P
2021-11-11 11:02 ` [PATCH 4/4] x86/mm: replace GFP_ATOMIC with GFP_KERNEL for direct map allocations Mike Rapoport
2021-11-11 15:19 ` Dave Hansen
2021-11-11 15:57 ` Mike Rapoport
2021-11-11 21:35 ` Edgecombe, Rick P
2021-11-12 12:30 ` Mike Rapoport
2021-11-12 22:39 ` Edgecombe, Rick P
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211111110241.25968-1-rppt@kernel.org \
--to=rppt@kernel.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rick.p.edgecombe@intel.com \
--cc=rppt@linux.ibm.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.