From: "H. Peter Anvin" <hpa@zytor.com>
To: Toshi Kani <toshi.kani@hp.com>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: tglx@linutronix.de, mingo@redhat.com, akpm@linux-foundation.org,
arnd@arndb.de, plagnioj@jcrosoft.com, tomi.valkeinen@ti.com,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
stefan.bader@canonical.com, luto@amacapital.net,
airlied@gmail.com, bp@alien8.de
Subject: Re: [RFC PATCH 0/11] Support Write-Through mapping on x86
Date: Mon, 21 Jul 2014 09:47:54 -0700 [thread overview]
Message-ID: <53CD443A.6050804@zytor.com> (raw)
In-Reply-To: <1405960298.30151.10.camel@misato.fc.hp.com>
On 07/21/2014 09:31 AM, Toshi Kani wrote:
> Do you have any comments / suggestions for this approach?
Approach to what, specifically?
Keep in mind the PAT bit is different for large pages. This needs to be
dealt with. I would also like a systematic way to deal with the fact
that Xen (sigh) is stuck with a separate mapping system.
I guess Linux could adopt the Xen mappings if that makes it easier, as
long as that doesn't have a negative impact on native hardware -- we can
possibly deal with some older chips not being optimal. However, my
thinking has been to have a "reverse PAT" table in memory of memory
types to encodings, both for regular and large pages.
-hpa
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: "H. Peter Anvin" <hpa@zytor.com>
To: Toshi Kani <toshi.kani@hp.com>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: tglx@linutronix.de, mingo@redhat.com, akpm@linux-foundation.org,
arnd@arndb.de, plagnioj@jcrosoft.com, tomi.valkeinen@ti.com,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
stefan.bader@canonical.com, luto@amacapital.net,
airlied@gmail.com, bp@alien8.de
Subject: Re: [RFC PATCH 0/11] Support Write-Through mapping on x86
Date: Mon, 21 Jul 2014 09:47:54 -0700 [thread overview]
Message-ID: <53CD443A.6050804@zytor.com> (raw)
In-Reply-To: <1405960298.30151.10.camel@misato.fc.hp.com>
On 07/21/2014 09:31 AM, Toshi Kani wrote:
> Do you have any comments / suggestions for this approach?
Approach to what, specifically?
Keep in mind the PAT bit is different for large pages. This needs to be
dealt with. I would also like a systematic way to deal with the fact
that Xen (sigh) is stuck with a separate mapping system.
I guess Linux could adopt the Xen mappings if that makes it easier, as
long as that doesn't have a negative impact on native hardware -- we can
possibly deal with some older chips not being optimal. However, my
thinking has been to have a "reverse PAT" table in memory of memory
types to encodings, both for regular and large pages.
-hpa
next prev parent reply other threads:[~2014-07-21 16:48 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-15 19:34 [RFC PATCH 0/11] Support Write-Through mapping on x86 Toshi Kani
2014-07-15 19:34 ` Toshi Kani
2014-07-15 19:34 ` [RFC PATCH 1/11] x86, mm, pat: Redefine _PAGE_CACHE_UC as UC_MINUS Toshi Kani
2014-07-15 19:34 ` Toshi Kani
2014-07-15 19:34 ` [RFC PATCH 2/11] x86, mm, pat: Define _PAGE_CACHE_WT for PA3/7 of PAT Toshi Kani
2014-07-15 19:34 ` Toshi Kani
2014-07-15 19:34 ` [RFC PATCH 3/11] x86, mm, pat: Change reserve_memtype() to handle WT type Toshi Kani
2014-07-15 19:34 ` Toshi Kani
2014-07-15 19:56 ` Andy Lutomirski
2014-07-15 19:56 ` Andy Lutomirski
2014-07-15 23:10 ` Toshi Kani
2014-07-15 23:10 ` Toshi Kani
2014-07-15 23:36 ` Andy Lutomirski
2014-07-15 23:36 ` Andy Lutomirski
2014-07-15 23:46 ` H. Peter Anvin
2014-07-15 23:46 ` H. Peter Anvin
2014-07-15 23:54 ` Andy Lutomirski
2014-07-15 23:54 ` Andy Lutomirski
2014-07-15 23:59 ` H. Peter Anvin
2014-07-15 23:59 ` H. Peter Anvin
2014-07-15 23:53 ` Toshi Kani
2014-07-15 23:53 ` Toshi Kani
2014-07-16 0:05 ` H. Peter Anvin
2014-07-16 0:05 ` H. Peter Anvin
2014-07-16 0:28 ` Andy Lutomirski
2014-07-16 0:28 ` Andy Lutomirski
2014-07-16 0:31 ` H. Peter Anvin
2014-07-16 0:31 ` H. Peter Anvin
2014-07-16 14:35 ` Toshi Kani
2014-07-16 14:35 ` Toshi Kani
2014-07-15 19:34 ` [RFC PATCH 4/11] x86, mm, asm-gen: Add ioremap_wt() for WT mapping Toshi Kani
2014-07-15 19:34 ` Toshi Kani
2014-07-15 19:34 ` [RFC PATCH 5/11] x86, mm: Add set_memory[_array]_wt() for setting WT Toshi Kani
2014-07-15 19:34 ` Toshi Kani
2014-07-15 19:34 ` [RFC PATCH 6/11] x86, mm, pat: Add pgprot_writethrough() for WT Toshi Kani
2014-07-15 19:34 ` Toshi Kani
2014-07-15 19:34 ` [RFC PATCH 7/11] x86, mm: Keep _set_memory_<type>() slot-independent Toshi Kani
2014-07-15 19:34 ` Toshi Kani
2014-07-15 19:34 ` [RFC PATCH 8/11] x86, mm, pat: Keep pgprot_<type>() slot-independent Toshi Kani
2014-07-15 19:34 ` Toshi Kani
2014-07-15 19:34 ` [RFC PATCH 9/11] x86, efi: Cleanup PCD bit manipulation in EFI Toshi Kani
2014-07-15 19:34 ` Toshi Kani
2014-07-15 19:34 ` [RFC PATCH 10/11] x86, xen: Cleanup PWT/PCD bit manipulation in Xen Toshi Kani
2014-07-15 19:34 ` Toshi Kani
2014-07-15 19:34 ` [RFC PATCH 11/11] x86, fbdev: Cleanup PWT/PCD bit manipulation in fbdev Toshi Kani
2014-07-15 19:34 ` Toshi Kani
2014-07-15 19:53 ` [RFC PATCH 0/11] Support Write-Through mapping on x86 Andy Lutomirski
2014-07-15 19:53 ` Andy Lutomirski
2014-07-15 20:10 ` H. Peter Anvin
2014-07-15 20:10 ` H. Peter Anvin
2014-07-15 20:09 ` H. Peter Anvin
2014-07-15 20:09 ` H. Peter Anvin
2014-07-15 21:23 ` Toshi Kani
2014-07-15 21:23 ` Toshi Kani
2014-07-16 0:40 ` Konrad Rzeszutek Wilk
2014-07-16 0:40 ` Konrad Rzeszutek Wilk
2014-07-16 21:28 ` Toshi Kani
2014-07-21 16:31 ` Toshi Kani
2014-07-21 16:47 ` H. Peter Anvin [this message]
2014-07-21 16:47 ` H. Peter Anvin
2014-07-21 17:16 ` Toshi Kani
2014-07-21 17:16 ` Toshi Kani
2014-07-21 17:32 ` H. Peter Anvin
2014-07-21 17:32 ` H. Peter Anvin
2014-07-21 17:33 ` Toshi Kani
2014-07-21 17:33 ` Toshi Kani
2014-07-21 18:33 ` Konrad Rzeszutek Wilk
2014-07-21 18:33 ` Konrad Rzeszutek Wilk
2014-07-21 19:24 ` Toshi Kani
2014-07-21 19:24 ` Toshi Kani
2014-07-21 20:22 ` H. Peter Anvin
2014-07-21 20:22 ` H. Peter Anvin
2014-07-21 17:20 ` Toshi Kani
2014-07-21 17:20 ` 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=53CD443A.6050804@zytor.com \
--to=hpa@zytor.com \
--cc=airlied@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=bp@alien8.de \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@amacapital.net \
--cc=mingo@redhat.com \
--cc=plagnioj@jcrosoft.com \
--cc=stefan.bader@canonical.com \
--cc=tglx@linutronix.de \
--cc=tomi.valkeinen@ti.com \
--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 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.