On Mon, 2014-09-08 at 10:23 -0700, Andy Lutomirski wrote: > On Sep 8, 2014 8:18 AM, "Toshi Kani" <toshi.kani@xxxxxx> wrote: > > > > On Sun, 2014-09-07 at 09:49 -0700, Andy Lutomirski wrote: > > > On Sun, Sep 7, 2014 at 1:49 AM, Yigal Korman <yigal@xxxxxxxxxxxxx> wrote: > > > > I think that what confused Andy (or at least me) is the documentation in Documentation/x86/pat.txt > > > > If it's possible, can you please update pat.txt as part of the patch? > > > > > > Indeed. That file seems to indicate several times that the intended > > > use of set_memory_xyz is for RAM. > > > > > > Good point. pat.txt is correct that the "intended" use of > > set_memory_xyz() is for RAM since there is no other way to set non-WB > > attribute for RAM. For reserved memory, one should call ioremap_xyz() > > to map with the xyz attribute directly. From the functionality POV, > > set_memory_xyz() works for reserved memory, but such usage is not > > intended. > > > > Should I drop the patch 4/5 until we can track the use of WT for RAM? > > Probably not. I can imagine someone ioremapping a huge chunk of > NV-DIMM and then wanting to change some of it to WT. Unless I've > missed something (which is rather likely), the cleanest way to do this > is with set_memory_wt. Yeah, that sounds possible. > If that happens, someone should update pat.txt to indicate that it's allowed. Since it is unlikely that someone will update pat.txt later, I will update it to: ------------------------------------------------------------------- API | RAM | ACPI,... | Reserved/Holes | -----------------------|----------|------------|------------------| set_memory_wt | *1 | -- | WT | set_memory_wb | | | | *1: -EINVAL due to the current limitation in reserve_memtype(). Thanks, -Toshi -- 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>