On Fri, Dec 13, 2024 at 01:34:41PM -0600, Elizabeth Figura wrote: > This patch series implements a new char misc driver, /dev/ntsync, which is used > to implement Windows NT synchronization primitives. > > NT synchronization primitives are unique in that the wait functions both are > vectored, operate on multiple types of object with different behaviour (mutex, > semaphore, event), and affect the state of the objects they wait on. This model > is not compatible with existing kernel synchronization objects or interfaces, > and therefore the ntsync driver implements its own wait queues and locking. > > This patch series is rebased against the "char-misc-next" branch of > gregkh/char-misc.git. > > == Background == > > The Wine project emulates the Windows API in user space. One particular part of > that API, namely the NT synchronization primitives, have historically been > implemented via RPC to a dedicated "kernel" process. However, more recent > applications use these APIs more strenuously, and the overhead of RPC has become > a bottleneck. > > The NT synchronization APIs are too complex to implement on top of existing > primitives without sacrificing correctness. Certain operations, such as > NtPulseEvent() or the "wait-for-all" mode of NtWaitForMultipleObjects(), require > direct control over the underlying wait queue, and implementing a wait queue > sufficiently robust for Wine in user space is not possible. This proposed > driver, therefore, implements the problematic interfaces directly in the Linux > kernel. > > This driver was presented at Linux Plumbers Conference 2023. For those further > interested in the history of synchronization in Wine and past attempts to solve > this problem in user space, a recording of the presentation can be viewed here: > > https://www.youtube.com/watch?v=NjU4nyWyhU8 > > > == Performance == > > The performance measurements described below are copied from earlier versions of > the patch set. While some of the code has changed, I do not currently anticipate > that it has changed drastically enough to affect those measurements. > > The gain in performance varies wildly depending on the application in question > and the user's hardware. For some games NT synchronization is not a bottleneck > and no change can be observed, but for others frame rate improvements of 50 to > 150 percent are not atypical. The following table lists frame rate measurements > from a variety of games on a variety of hardware, taken by users Dmitry > Skvortsov, FuzzyQuils, OnMars, and myself: > > Game Upstream ntsync improvement > =========================================================================== > Anger Foot 69 99 43% > Call of Juarez 99.8 224.1 125% > Dirt 3 110.6 860.7 678% > Forza Horizon 5 108 160 48% > Lara Croft: Temple of Osiris 141 326 131% > Metro 2033 164.4 199.2 21% > Resident Evil 2 26 77 196% > The Crew 26 51 96% > Tiny Tina's Wonderlands 130 360 177% > Total War Saga: Troy 109 146 34% > =========================================================================== > > > == Patches == > > The intended semantics of the patches are broadly intended to match those of the > corresponding Windows functions. For those not already familiar with the Windows > functions (or their undocumented behaviour), patch 27/28 provides a detailed > specification, and individual patches also include a brief description of the > API they are implementing. > > The patches making use of this driver in Wine can be retrieved or browsed here: > > https://repo.or.cz/wine/zf.git/shortlog/refs/heads/ntsync7 > Given a lack of complaints, I've now applied this to my testing tree. Thanks for sticking with it! greg k-h
