Windows NT Synchronization Primitive Driver Updated For The Linux Kernel

[QwertyChouskie]

Yes, yes. All Windows users use WSL and run Linux programs .

Most Windows users don't have a clue what WSL is and what it is used for. And they are fine with that.

Most "big ticket" Linux apps (e.g. GIMP/Krita) have native Windows versions, due to the nature of FOSS software. (The exceptions are usually CLI and developer-focused stuff, which is what WSL was primarily designed for.) Meanwhile, "big ticket" Windows applications are much less likely to have native Linux versions, due to the nature of proprietary software, making Wine/Proton/etc much more important.

[varikonniemi]

The power of Windows. Windows is so desirable that even Linux has become similar to it. Life without Windows programs would be sad.


Back to the topic. Proton, Lutris do not use evenfd (esync)?

Scereen from NTSYNC presentation. Hmm, performance increases relative to what is there now seem not very large. In fact is zero.

_1111.jpg


You can also take a look here: FlightlessMango

NTSYNC has a minimum increment, and in 1% zero.

58 vs 62 degrees core temperature shows tremendous efficiency gain with ntsync, probably because wine with it works more like the windows the program expects/was designed for.

[oiaohm]

Lot of people don't think why now. The reality NT sync structures used inside windows last major change documented in Microsoft API documentation is Windows XP SP1a this is the year 2003. This area of windows has just aged out of possible being covered by software patents.

Its not a new idea to move these parts into kernel.

https://en.wikipedia.org/wiki/Longene

Longene and kernel-win32 before it had the same idea.

Yes we are seeing wine starting to piece by piece have more Linux kernel particular assistance.

By the way benchmarking against eventdfd and futex_waitv is basically pointless because those things are not going to merge Wine mainline because of where they cannot match Windows behavior..

Just like how Linux implemented BSD and Posix functionality that duplicate each other nothing prevents Linux kernel implementing NTsync and other parts that have fallen out of patent protection.

Also I don't see any particular reason why someone porting a Windows program to linux after ntsync is merged could not use windows sync primitives in native LInux program.

[Danny3]

Nice!
I hope that this time it will be merged or at least more people will comment / come with ideas to be improved so it can be merged next time.
Gaming is really important and the Linux kernel should offer the best support and efficiency for such a task!
If Steam Deck is really successful the the whole Linux environment will get better drivers, support, donations, acknowledgement!

[varikonniemi]

Lot of people don't think why now. The reality NT sync structures used inside windows last major change documented in Microsoft API documentation is Windows XP SP1a this is the year 2003. This area of windows has just aged out of possible being covered by software patents.

Its not a new idea to move these parts into kernel.

https://en.wikipedia.org/wiki/Longene

Longene and kernel-win32 before it had the same idea.

Yes we are seeing wine starting to piece by piece have more Linux kernel particular assistance.

By the way benchmarking against eventdfd and futex_waitv is basically pointless because those things are not going to merge Wine mainline because of where they cannot match Windows behavior..

Just like how Linux implemented BSD and Posix functionality that duplicate each other nothing prevents Linux kernel implementing NTsync and other parts that have fallen out of patent protection.

Also I don't see any particular reason why someone porting a Windows program to linux after ntsync is merged could not use windows sync primitives in native LInux program.

ntsync will have marginally worse performance, but it won't matter if using it will simplify the porting process. What i don't know is if such a situation would naturally arise?

[oiaohm]

ntsync will have marginally worse performance, but it won't matter if using it will simplify the porting process. What i don't know is if such a situation would naturally arise?

https://learn.microsoft.com/en-us/windows/win32/sync/waiting-for-multiple-objects

This is a fun thing added in XP.Yes futex_waitv gives part support for waiting for multiple objects. Futex_waitv has a 128 limit but the windows WaitForMultipleObjects technical max is 32 bit unsigned. dword. Yes eventfd does not handle this case well at all.

This is only one example. There are many cases where a highly optimized windows program to take advantage of Windows sync structures runs into limits of the sync structures Linux/BSD/MacOS/Unix offer.

Windows behavior in this area of sync is different to what the Posix world normally provides. Kind of makes sense that Windows NT design is more based on VMS than anything else.

The issue really is how to match Windows behavior without being slow. Yes the broken cases are like where some windows program decides to wait on 256+ different things and now it does not fit in futex_waitv and so on.

[Weasel]

Not really. ntsync is more formally correct, but actually very few applications use those edge cases. So "more buggy" is in practice not too significant for esync / fsync.

fsync maybe. esync is full of issues (if you look at protondb for instance)

[Weasel]

Lot of people don't think why now. The reality NT sync structures used inside windows last major change documented in Microsoft API documentation is Windows XP SP1a this is the year 2003. This area of windows has just aged out of possible being covered by software patents.

Its not a new idea to move these parts into kernel.

https://en.wikipedia.org/wiki/Longene

Longene and kernel-win32 before it had the same idea.

Yes we are seeing wine starting to piece by piece have more Linux kernel particular assistance.

By the way benchmarking against eventdfd and futex_waitv is basically pointless because those things are not going to merge Wine mainline because of where they cannot match Windows behavior..

Just like how Linux implemented BSD and Posix functionality that duplicate each other nothing prevents Linux kernel implementing NTsync and other parts that have fallen out of patent protection.

Also I don't see any particular reason why someone porting a Windows program to linux after ntsync is merged could not use windows sync primitives in native LInux program.

Why port when you can just use Wine and have it done for you?

But yes, ntsync is about performance and compatibility. Not just performance like fsync/esync.

wineserver is correct but slow af because of IPC and synchronization (between app and wineserver, not the NT synchronization itself which happens regardless).

[F.Ultra]

Yes, yes. All Windows users use WSL and run Linux programs .

Most Windows users don't have a clue what WSL is and what it is used for. And they are fine with that.

And yet Microsoft have invested several orders of magnitude more money and resources into WSL than the community have in WINE.

[J.King]

Why port when you can just use Wine and have it done for you?

For GUI software, the ability to integrate with the rest of the desktop environment, or the operating system as a whole. For games the case is probably weaker, but I could see someone wanting to port something which has a kernel-level anti-cheat, maybe? For all software, Wine adds very significant start-up overhead (several seconds), so avoiding that is certainly useful.