Re: [RFC PATCH 0/11] Support Write-Through mapping on x86

From: Konrad Rzeszutek Wilk
Date: Tue Jul 15 2014 - 20:44:31 EST

On July 15, 2014 5:23:24 PM EDT, Toshi Kani <toshi.kani@xxxxxx> wrote:
>On Tue, 2014-07-15 at 13:09 -0700, H. Peter Anvin wrote:
>> On 07/15/2014 12:34 PM, Toshi Kani wrote:
>> > This RFC patchset is aimed to seek comments/suggestions for the
>> > and changes to support of Write-Through (WT) mapping. The study
>> > shows that using WT mapping may be useful for non-volatile memory.
>> >
>> >
>> >
>> > There were idea & patches to support WT in the past, which
>> > very valuable discussions on this topic.
>> >
>> >
>> >
>> >
>> >
>> > This RFC patchset tries to address the issues raised by taking the
>> > following design approach:
>> >
>> > - Keep the MTRR interface
>> > - Keep the WB, WC, and UC- slots in the PAT MSR
>> > - Keep the PAT bit unused
>> > - Reassign the UC slot to WT in the PAT MSR
>> >
>> > There are 4 usable slots in the PAT MSR, which are currently
>assigned to:
>> >
>> > PA0/4: WB, PA1/5: WC, PA2/6: UC-, PA3/7: UC
>> >
>> > The PAT bit is unused since it shares the same bit as the PSE bit
>> > there was a bug in older processors. Among the 4 slots, the
>> > memory type consumes 2 slots, UC- and UC. They are functionally
>> > equivalent, but UC- allows MTRRs to overwrite it with WC. All
>> > that set the uncached memory type use UC- in order to work with
>> > The PA3/7 slot is effectively unused today. Therefore, this
>> > reassigns the PA3/7 slot to WT. If MTRRs get deprecated in future,
>> > UC- can be reassigned to UC, and there is still no need to consume
>> > 2 slots for the uncached memory type.
>> Not going to happen any time in the forseeable future.
>> Furthermore, I don't think it is a big deal if on some old, buggy
>> processors we take the performance hit of cache type demotion, as
>> as we don't actively lose data.
>> > This patchset is consist of two parts. The 1st part, patch [1/11]
>> > [6/11], enables WT mapping and adds new interfaces for setting WT
>> > The 2nd part, patch [7/11] to [11/11], cleans up the code that has
>> > internal knowledge of the PAT slot assignment. This keeps the
>> > code independent from the PAT slot assignment.
>> I have given this piece of feedback at least three times now,
>> to different people, and I'm getting a bit grumpy about it:
>> We already have an issue with Xen, because Xen assigned mappings
>> differently and it is incompatible with the use of PAT in Linux. As
>> result we get requests for hacks to work around this, which is
>> I really don't want to see. I would like to see a design involving a
>> "reverse PAT" table where the kernel can hold the mapping between
>> types and page table encodings (including the two different ones for
>> small and large pages.)
>Thanks for pointing this out! (And sorry for making you repeat it three
>time...) I was not aware of the issue with Xen. I will look into the
>email archive to see what the Xen issue is, and how it can be

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at