From: mpeg.blue@free.fr (Mason)
To: linux-arm-kernel@lists.infradead.org
Subject: Creating 16 MB super-sections for MMIO
Date: Wed, 03 Dec 2014 15:20:01 +0100 [thread overview]
Message-ID: <547F1C11.5090408@free.fr> (raw)
In-Reply-To: <20141203103211.GB7373@e104818-lin.cambridge.arm.com>
Hello Catalin,
On 03/12/2014 11:32, Catalin Marinas wrote:
> The reasons behind this proposal aren't clear. Are you trying
> to optimise mmio register accesses by avoiding TLB misses?
I am trying to minimize TLB "pollution" by using a "huge" page.
The ARM manual states: "Support for Supersections, Sections and
Large pages enables a large region of memory to be mapped using
only a single entry in the TLB."
Is it correct that, if I create a virtual-to-physical mapping of
an 8 MB memory region, then, in the best-case scenario, the kernel
will create 8 Sections? Thus my mapping would use up to 8 entries
in the TLB at any given time.
Instead, if I create a V2P mapping of a 16 MB region, and if the
kernel supports so-called Super-sections, then the mapping would
use only a single entry in the TLB. Right?
Thus creating a Super-section leaves more TLB entries available
for user-space processes and kernel threads, which can only
improve system performance, AFAIU.
On my SoC, physical addresses 0 to 2^24 are reserved for device
memory-mapped registers. There are holes in the region (meaning
addresses that don't map to any register) but the bus is defined
in such a way that
- writing to a hole is a NOP,
-reading from a hole returns 0.
So I'd like to map
physical addresses 0-2^24
to
virtual addresses 0xf000_0000 - 0xf100_0000
using a Super-section.
And I was hoping that calling iotable_init with a struct map_desc
entry where length = SZ_16M would create such a super-section.
Did that make sense?
As far as I could tell, Linux does not create a super-section in the
case outlined above. Perhaps I misread the source code?
Regards.
WARNING: multiple messages have this Message-ID (diff)
From: Mason <mpeg.blue@free.fr>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Linux ARM <linux-arm-kernel@lists.infradead.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: Creating 16 MB super-sections for MMIO
Date: Wed, 03 Dec 2014 15:20:01 +0100 [thread overview]
Message-ID: <547F1C11.5090408@free.fr> (raw)
In-Reply-To: <20141203103211.GB7373@e104818-lin.cambridge.arm.com>
Hello Catalin,
On 03/12/2014 11:32, Catalin Marinas wrote:
> The reasons behind this proposal aren't clear. Are you trying
> to optimise mmio register accesses by avoiding TLB misses?
I am trying to minimize TLB "pollution" by using a "huge" page.
The ARM manual states: "Support for Supersections, Sections and
Large pages enables a large region of memory to be mapped using
only a single entry in the TLB."
Is it correct that, if I create a virtual-to-physical mapping of
an 8 MB memory region, then, in the best-case scenario, the kernel
will create 8 Sections? Thus my mapping would use up to 8 entries
in the TLB at any given time.
Instead, if I create a V2P mapping of a 16 MB region, and if the
kernel supports so-called Super-sections, then the mapping would
use only a single entry in the TLB. Right?
Thus creating a Super-section leaves more TLB entries available
for user-space processes and kernel threads, which can only
improve system performance, AFAIU.
On my SoC, physical addresses 0 to 2^24 are reserved for device
memory-mapped registers. There are holes in the region (meaning
addresses that don't map to any register) but the bus is defined
in such a way that
- writing to a hole is a NOP,
-reading from a hole returns 0.
So I'd like to map
physical addresses 0-2^24
to
virtual addresses 0xf000_0000 - 0xf100_0000
using a Super-section.
And I was hoping that calling iotable_init with a struct map_desc
entry where length = SZ_16M would create such a super-section.
Did that make sense?
As far as I could tell, Linux does not create a super-section in the
case outlined above. Perhaps I misread the source code?
Regards.
next prev parent reply other threads:[~2014-12-03 14:20 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-02 10:42 Creating 16 MB super-sections for MMIO Mason
2014-12-03 9:52 ` Mason
2014-12-03 9:52 ` Mason
2014-12-03 10:32 ` Catalin Marinas
2014-12-03 10:32 ` Catalin Marinas
2014-12-03 14:20 ` Mason [this message]
2014-12-03 14:20 ` Mason
2014-12-03 17:06 ` Arnd Bergmann
2014-12-03 17:06 ` Arnd Bergmann
2014-12-03 17:47 ` Mason
2014-12-03 17:47 ` Mason
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=547F1C11.5090408@free.fr \
--to=mpeg.blue@free.fr \
--cc=linux-arm-kernel@lists.infradead.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.