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

[H. Peter Anvin]

On 07/21/2014 10:16 AM, Toshi Kani wrote:
> 
> You are right.  I was under a wrong impression that
> __change_page_attr() always splits a large pages into 4KB pages, but I
> overlooked the fact that it can handle a large page as well.  So, this
> approach does not work...
> 

If it did it would be a major fail.

>> 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.  
> 
> I see.  I agree that supporting the PAT bit is the right direction, but
> I do not know how much effort we need.  I will study on this.
> 
>> However, my thinking has been to have a "reverse PAT" table in memory of memory
>> types to encodings, both for regular and large pages.
> 
> I am not clear about your idea of the "reverse PAT" table.  Would you
> care to elaborate?  How is it different from using pte_val() being a
> paravirt function on Xen?

First of all, paravirt functions are the root of all evil, and we want
to reduce and eliminate them to the utmost level possible.  But yes, we
could plumb that up that way if we really need to.

What I'm thinking of is a table which can deal with both the moving PTE
bit, Xen, and the scattered encodings by having a small table from types
to encodings, and not use the encodings directly until fairly late it
the pipe.  I suspect, but I'm not sure, that we would also need the
inverse operation.

	-hpa


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/