linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Toshi Kani <toshi.kani@hp.com>
To: akpm@linux-foundation.org, hpa@zytor.com, tglx@linutronix.de,
	mingo@redhat.com, arnd@arndb.de
Cc: linux-mm@kvack.org, x86@kernel.org, linux-kernel@vger.kernel.org,
	dave.hansen@intel.com, Elliott@hp.com
Subject: [PATCH v3 0/6] Kernel huge I/O mapping support
Date: Tue,  3 Mar 2015 10:44:18 -0700	[thread overview]
Message-ID: <1425404664-19675-1-git-send-email-toshi.kani@hp.com> (raw)

ioremap() and its related interfaces are used to create I/O
mappings to memory-mapped I/O devices.  The mapping sizes of
the traditional I/O devices are relatively small.  Non-volatile
memory (NVM), however, has many GB and is going to have TB soon.
It is not very efficient to create large I/O mappings with 4KB. 

This patchset extends the ioremap() interfaces to transparently
create I/O mappings with huge pages whenever possible.  ioremap()
continues to use 4KB mappings when a huge page does not fit into
a requested range.  There is no change necessary to the drivers
using ioremap().  A requested physical address must be aligned by
a huge page size (1GB or 2MB on x86) for using huge page mapping,
though.  The kernel huge I/O mapping will improve performance of
NVM and other devices with large memory, and reduce the time to
create their mappings as well.

On x86, MTRRs can override PAT memory types with a 4KB granularity.
When using a huge page, MTRRs can override the memory type of the
huge page, which may lead a performance penalty.  The processor can
also behave in an undefined manner if a huge page is mapped to a
memory range that MTRRs have mapped with multiple different memory
types.  Therefore, the mapping code falls back to use a smaller page
size toward 4KB when a mapping range is covered by non-WB type of
MTRRs. The WB type of MTRRs has no affect on the PAT memory types.

The patchset introduces HAVE_ARCH_HUGE_VMAP, which indicates that
the arch supports huge KVA mappings for ioremap().  User may specify
a new kernel option "nohugeiomap" to disable the huge I/O mapping
capability of ioremap() when necessary.

Patch 1-4 change common files to support huge I/O mappings.  There
is no change in the functinalities unless HAVE_ARCH_HUGE_VMAP is
defined on the architecture of the system.

Patch 5-6 implement the HAVE_ARCH_HUGE_VMAP funcs on x86, and set
HAVE_ARCH_HUGE_VMAP on x86.

--
v3:
 - Removed config HUGE_IOMAP. Always enable huge page mappings to
   ioremap() when supported by the arch. (Ingo Molnar)
 - Added checks to use 4KB mappings when a memory range is covered
   by MTRRs. (Ingo Molnar, Andrew Morton)
 - Added missing PAT bit handlings to the huge page mapping funcs.

v2:
 - Addressed review comments. (Andrew Morton)
 - Changed HAVE_ARCH_HUGE_VMAP to require X86_PAE set on X86_32.
 - Documented a x86 restriction with multiple MTRRs with different
   memory types.

---
Toshi Kani (6):
  1/6 mm: Change __get_vm_area_node() to use fls_long()
  2/6 lib: Add huge I/O map capability interfaces
  3/6 mm: Change ioremap to set up huge I/O mappings
  4/6 mm: Change vunmap to tear down huge KVA mappings
  5/6 x86, mm: Support huge I/O mapping capability I/F
  6/6 x86, mm: Support huge KVA mappings on x86

---
 Documentation/kernel-parameters.txt |  2 ++
 arch/Kconfig                        |  3 ++
 arch/x86/Kconfig                    |  1 +
 arch/x86/include/asm/page_types.h   |  2 ++
 arch/x86/mm/ioremap.c               | 23 +++++++++++--
 arch/x86/mm/pgtable.c               | 65 +++++++++++++++++++++++++++++++++++++
 include/asm-generic/pgtable.h       | 19 +++++++++++
 include/linux/io.h                  |  7 ++++
 init/main.c                         |  2 ++
 lib/ioremap.c                       | 54 ++++++++++++++++++++++++++++++
 mm/vmalloc.c                        |  8 ++++-
 11 files changed, 183 insertions(+), 3 deletions(-)

             reply	other threads:[~2015-03-03 17:45 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-03 17:44 Toshi Kani [this message]
2015-03-03 17:44 ` [PATCH v3 1/6] mm: Change __get_vm_area_node() to use fls_long() Toshi Kani
2015-03-03 17:44 ` [PATCH v3 2/6] lib: Add huge I/O map capability interfaces Toshi Kani
2015-03-03 17:44 ` [PATCH v3 3/6] mm: Change ioremap to set up huge I/O mappings Toshi Kani
2015-03-04 22:09   ` Ingo Molnar
2015-03-04 23:15     ` Toshi Kani
2015-03-03 17:44 ` [PATCH v3 4/6] mm: Change vunmap to tear down huge KVA mappings Toshi Kani
2015-03-03 17:44 ` [PATCH v3 5/6] x86, mm: Support huge I/O mapping capability I/F Toshi Kani
2015-03-03 17:44 ` [PATCH v3 6/6] x86, mm: Support huge KVA mappings on x86 Toshi Kani
2015-03-03 22:44   ` Andrew Morton
2015-03-03 23:14     ` Toshi Kani
2015-03-04  1:00       ` Andrew Morton
2015-03-04 16:23         ` Toshi Kani
2015-03-04 20:17           ` Ingo Molnar
2015-03-04 21:16             ` Toshi Kani

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=1425404664-19675-1-git-send-email-toshi.kani@hp.com \
    --to=toshi.kani@hp.com \
    --cc=Elliott@hp.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=dave.hansen@intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@redhat.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 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).