On Thu, 27 Jul 2023 at 01:06, Paul Gofman pgofman@codeweavers.com wrote:
Hello Michał,
I was looking into that from the Wine point of view and did a bitof testing, so will try to answer the question cited below.
Thanks for the extensive explanation!
Without Windows large pages I guess the only way to make this workcorrectly is to disable THP with madvise(MADV_NOHUGEPAGE) on the memory ranges allocated with MEM_WRITE_WATCH, as the memory changes should not only be reported but also tracked with 4k page granularity as Windows applications expect.
Currently we don't implement MEM_LARGE_PAGES flag support in Wine(while of course might want to do that in the future). On Windows using this flag requires special permissions and implies more than just using huge pages under the hood but also, in particular, locking pages in memory. I'd expect that support to be extended in Windows though in the future in some way. WRT write watches, the range is watched with large page granularity. GetWriteWatch lpdwGranularity output parameter returns the value of "large page minimum" (returned by GetLargePageMinimum) and the returned addresses correspond to those large pages. I suppose to implement that on top of Linux huge pages we'd need a way to control huge pages allocation at the first place, i. e., a way to enforce the specified size for the huge pages for the memory ranged being mapped. Without that I am afraid the only way to correctly implement that is to still disable THP on the range and only adjust our API output so that matches expected.
Not related to the question, but without any relation to Wine andWindows API current way of dealing with THP in the API design looks a bit not straightforward to me. In a sense that transparent huge pages will appear not so transparent when it comes to dirty pages tracking. If I understand correctly, the application which allocated a reasonably big memory area and didn't use madvise(MADV_NOHUGEPAGE) might end up with a whole range being a single page and getting dirtified as a whole, which may likely void app's optimization based on changed memory tracking. Not that I know an ideal way out of this, maybe it is a matter of having THP disabled by default on watched ranges or clearly warning about this caveat in documentation?
So, this means that the max_pages limit should count HugeTLB pages as 1 not HPAGE_SIZE/PAGE_SIZE pages. Also, to get this right, we might need another PAGE_IS_HUGETLB category, so that userspace can differentiate the ranges if needed.
Is it possible (on Windows) to have MEM_LARGE_PAGES allocation near a normal one and run GetWriteWatch() on both in one call? If so, how does it behave / what is expected?
Best Regards Michał Mirosław