From: tip-bot for Andy Lutomirski <tipbot@zytor.com>
To: linux-tip-commits@vger.kernel.org
Cc: dvlasenk@redhat.com, peterz@infradead.org, luto@amacapital.net,
tglx@linutronix.de, luto@kernel.org, brgerst@gmail.com,
jdelvare@suse.de, mingo@kernel.org, toshi.kani@hp.com,
torvalds@linux-foundation.org, mcgrof@suse.com, hpa@zytor.com,
bp@alien8.de, arjan@linux.intel.com, akpm@linux-foundation.org,
linux-kernel@vger.kernel.org
Subject: [tip:x86/mm] x86/dmi: Switch dmi_remap() from ioremap() [uncached ] to ioremap_cache()
Date: Tue, 9 Feb 2016 08:08:32 -0800 [thread overview]
Message-ID: <tip-ce1143aa60273220a9f89012f2aaaed04f97e9a2@git.kernel.org> (raw)
In-Reply-To: <3147c38e51f439f3c8911db34c7d4ab22d854915.1453791969.git.luto@kernel.org>
Commit-ID: ce1143aa60273220a9f89012f2aaaed04f97e9a2
Gitweb: http://git.kernel.org/tip/ce1143aa60273220a9f89012f2aaaed04f97e9a2
Author: Andy Lutomirski <luto@kernel.org>
AuthorDate: Mon, 25 Jan 2016 23:06:49 -0800
Committer: Ingo Molnar <mingo@kernel.org>
CommitDate: Tue, 9 Feb 2016 14:36:43 +0100
x86/dmi: Switch dmi_remap() from ioremap() [uncached] to ioremap_cache()
DMI cacheability is very confused on x86.
dmi_early_remap() uses early_ioremap(), which uses FIXMAP_PAGE_IO,
which is __PAGE_KERNEL_IO, which is __PAGE_KERNEL, which is cached.
Don't ask me why this makes any sense.
dmi_remap() uses ioremap(), which requests an uncached mapping.
However, on non-EFI systems, the DMI data generally lives between
0xf0000 and 0x100000, which is in the legacy ISA range, which
triggers a special case in the PAT code that overrides the cache
mode requested by ioremap() and forces a WB mapping.
On a UEFI boot, however, the DMI table can live at any physical
address. On my laptop, it's around 0x77dd0000. That's nowhere near
the legacy ISA range, so the ioremap() implicit uncached type is
honored and we end up with a UC- mapping.
UC- is a very, very slow way to read from main memory, so dmi_walk()
is likely to take much longer than necessary.
Given that, even on UEFI, we do early cached DMI reads, it seems
safe to just ask for cached access. Switch to ioremap_cache().
I haven't tried to benchmark this, but I'd guess it saves several
milliseconds of boot time.
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jean Delvare <jdelvare@suse.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Luis R. Rodriguez <mcgrof@suse.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Toshi Kani <toshi.kani@hp.com>
Link: http://lkml.kernel.org/r/3147c38e51f439f3c8911db34c7d4ab22d854915.1453791969.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
arch/x86/include/asm/dmi.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/dmi.h b/arch/x86/include/asm/dmi.h
index 535192f..3c69fed 100644
--- a/arch/x86/include/asm/dmi.h
+++ b/arch/x86/include/asm/dmi.h
@@ -15,7 +15,7 @@ static __always_inline __init void *dmi_alloc(unsigned len)
/* Use early IO mappings for DMI because it's initialized early */
#define dmi_early_remap early_ioremap
#define dmi_early_unmap early_iounmap
-#define dmi_remap ioremap
+#define dmi_remap ioremap_cache
#define dmi_unmap iounmap
#endif /* _ASM_X86_DMI_H */
next prev parent reply other threads:[~2016-02-09 16:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-26 7:06 [PATCH] x86/dmi: Switch dmi_remap to ioremap_cache Andy Lutomirski
2016-02-09 16:08 ` tip-bot for Andy Lutomirski [this message]
2017-03-09 17:48 ` Julian Brost
2017-03-09 17:51 ` Arjan van de Ven
2017-03-09 18:03 ` Julian Brost
2017-03-09 18:14 ` Andy Lutomirski
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=tip-ce1143aa60273220a9f89012f2aaaed04f97e9a2@git.kernel.org \
--to=tipbot@zytor.com \
--cc=akpm@linux-foundation.org \
--cc=arjan@linux.intel.com \
--cc=bp@alien8.de \
--cc=brgerst@gmail.com \
--cc=dvlasenk@redhat.com \
--cc=hpa@zytor.com \
--cc=jdelvare@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=luto@kernel.org \
--cc=mcgrof@suse.com \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=toshi.kani@hp.com \
/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
Powered by JetHome