On Mon Jun 3 16:19:12 2024 +0000, Paul Gofman wrote:
> As a general note, please don't put the changes to earlier patches on
> top, just modify the patches. We also start the patch names from the
> name of the component the patch is modifying, like: "ntdll: Support xxx
> in NtYYY()." It would probably help to look at some merged MRs and
> commit history for examples.
I'm sorry, what are the "earlier patches" in this context? Also, I was not entirely sure what the component modified would be, as both NtCreationSection and CreateFileMapping would be affected by the patch, which are in different components. Would wineserver be appropriate?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5769#note_72234
This should help unifying the interface and get rid of the get_info callback.
Later, I think we could create bitmaps over sections shared with some DWM process and/or host compositor.
--
v3: win32u: Create a HBITMAP backing the window surface pixels.
winex11: Create a HBITMAP for the allocated surface pixels.
winex11: Create XImage before initializing the window surface.
winex11: Simplify the XSHM extension function calls.
win32u: Pass BITMAPINFO and a HBITMAP to window_surface_init.
win32u: Move the window surface color bits to the common struct.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5764
As a general note, please don't put the changes to earlier patches on top, just modify the patches. We also start the patch names from the name of the component the patch is modifying, like: "ntdll: Support xxx in NtYYY()." It would probably help to look at some merged MRs and commit history for examples.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5769#note_72228
On Sun Jun 2 15:41:59 2024 +0000, Vibhav Pant wrote:
> From what I understand, THP support is ultimately immaterial here, as
> we're **requiring** a huge page allocation, rather than depending on
> `khugepaged`to compact `madvise`-ed ranges.
Still, are the large page sizes on Windows match those on Linux? I think in Wine we have to support what Windows supports and report the same minimum page size that Windows reports. If that can be backed by actual huge pages then great but I am not sure if we can sacrifice compatibility here. Depends on usage pattern probably but I wouldn't expect the actually backing the range with huge pages to have all that great performance impact.
Also, just as a note, mind that those huge pages allocation on Windows have other specifics, like IIRC they are always locked in memory. That potentially can have more impact than actual backing pages layout. I am wondering what does the app which uses it actually does with this mapping?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5769#note_72227
On Mon Jun 3 12:33:42 2024 +0000, Vibhav Pant wrote:
> changed this line in [version 7 of the diff](/wine/wine/-/merge_requests/5769/diffs?diff_id=116330&start_sha=d9cab6b6298f63cccffebb8a71e6ca56d4a3f871#2b37d5dc1c3bb6a637f043480c038caea64531bb_342_342)
While of course memfd can be accessed quicker than disk storage that doesn't justify backing all the anonymous mappings with memfd. Even for executable images only it may be very lot.
In the other thread you are mentioning Proton patch doing something similar. I think that was motivated as a workaround for a specific problems with specific types of mappings and probably would be better to be changed.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5769#note_72226
This MR adds support for creating file mapping objects backed by large pages on Linux, by making the following changes:
## wineserver
* On Linux, `create_temp_file` will first attempt to use memfds as the backing fd. If it fails, it'll return to the current codepath, creating a temporary file in either the server or config directory.
* The created memfd will be sealed against writes, if the caller requesting the appropriate page protection flags.
* This removes the requirement that FDs be only created on filesystems/directories that aren't `noexec`.
* In the server method `create_mapping` , if large pages have been requested by the caller, hold that the calling thread's token holds `SeLockMemoryPrivilege` .
* Additionally, add `SeLockMemoryPrivilege` to the list of privileges enabled for the Administrator.
## `ntdll`
* Add `virtual_get_min_large_page_size` and its exported wrapper `wine_unix_get_min_large_page_size`.
* On Linux, the minimum page size is determined by going through `/sys/kernel/mm/hugepages`. If hugepage support was not detected, `STATUS_NOT_SUPPORTED` is returned instead. On other platforms, the older hard-coded value of 2\*1024\*1024 is returned instead.
* `NtCreateSection` will validate certain parameters if large pages are requested. Specifically, it will return STATUS_INVALID_PARAMETER if the requested mapping is not anonymous/unnamed, or the size is not a multiple of the minimum supported page size.
## `kernelbase`
* `GetLargePageMinimum` will use `wine_unix_get_min_large_page_size`.
## `kernel32/tests`
* Add new test test_large_page_file_mapping, which validates privilege enforcements and parameter validation while creating large pages backed file mapping obejcts. The tests are skipped if `GetLargePageMinimum` returns 0.
--
v10: make_memfd_name: Fix format specifiers.
This merge request has too many patches to be relayed via email.
Please visit the URL below to see the contents of the merge request.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5769
This should help unifying the interface and get rid of the get_info callback.
Later, I think we could create bitmaps over sections shared with some DWM process and/or host compositor.
--
v2: win32u: Create a HBITMAP backing the window surface pixels.
winex11: Create a HBITMAP for the allocated surface pixels.
winex11: Create XImage before initializing the window surface.
win32u: Pass BITMAPINFO and a HBITMAP to window_surface_init.
win32u: Move the window surface color bits to the common struct.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5764