On Thu, 27 Jul 2023 at 01:06, Paul Gofman <pgofman@xxxxxxxxxxxxxxx> wrote: > > Hello Michał, > > I was looking into that from the Wine point of view and did a bit > of 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 work > correctly 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 and > Windows 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
