From: Christoph Lameter <cl@linux.com>
To: Sudarshan Rajagopalan <sudaraja@codeaurora.org>
Cc: linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Anshuman Khandual <anshuman.khandual@arm.com>,
David Hildenbrand <david@redhat.com>,
Mike Rapoport <rppt@linux.ibm.com>,
Mark Rutland <mark.rutland@arm.com>,
Logan Gunthorpe <logang@deltatee.com>,
Andrew Morton <akpm@linux-foundation.org>,
Steven Price <steven.price@arm.com>,
Suren Baghdasaryan <surenb@google.com>
Subject: Re: [PATCH 1/1] arm64/sparsemem: reduce SECTION_SIZE_BITS
Date: Thu, 21 Jan 2021 10:08:17 +0000 (UTC) [thread overview]
Message-ID: <alpine.DEB.2.22.394.2101211004540.100764@www.lameter.com> (raw)
In-Reply-To: <43843c5e092bfe3ec4c41e3c8c78a7ee35b69bb0.1611206601.git.sudaraja@codeaurora.org>
On Wed, 20 Jan 2021, Sudarshan Rajagopalan wrote:
> But there are other problems in reducing SECTION_SIZE_BIT. Reducing it by too
> much would over populate /sys/devices/system/memory/ and also consume too many
> page->flags bits in the !vmemmap case. Also section size needs to be multiple
> of 128MB to have PMD based vmemmap mapping with CONFIG_ARM64_4K_PAGES.
There is also the issue of requiring more space in the TLB cache with
smaller page sizes. Or does ARM resolve these into smaller TLB entries
anyways (going on my x86 kwon how here)? Anyways if there are only a few
TLB entries then the effect could
be significant.
next prev parent reply other threads:[~2021-01-21 10:09 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-21 5:29 [PATCH 0/1] arm64/sparsemem: reduce SECTION_SIZE_BITS Sudarshan Rajagopalan
2021-01-21 5:29 ` [PATCH 1/1] " Sudarshan Rajagopalan
2021-01-21 10:08 ` Christoph Lameter [this message]
2021-01-21 15:54 ` Catalin Marinas
2021-01-21 13:36 ` Will Deacon
2021-01-22 2:58 ` Anshuman Khandual
2021-01-21 13:45 ` David Hildenbrand
2021-01-21 14:16 ` Mike Rapoport
2021-01-21 16:04 ` David Hildenbrand
2021-01-21 15:51 ` Catalin Marinas
2021-01-21 18:26 ` [PATCH 0/1] " Will Deacon
2021-01-29 0:17 ` Pavel Tatashin
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=alpine.DEB.2.22.394.2101211004540.100764@www.lameter.com \
--to=cl@linux.com \
--cc=akpm@linux-foundation.org \
--cc=anshuman.khandual@arm.com \
--cc=catalin.marinas@arm.com \
--cc=david@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=logang@deltatee.com \
--cc=mark.rutland@arm.com \
--cc=rppt@linux.ibm.com \
--cc=steven.price@arm.com \
--cc=sudaraja@codeaurora.org \
--cc=surenb@google.com \
--cc=will@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).