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, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>