From: Elizabeth Figura <zfigura@codeweavers.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: "Arnd Bergmann" <arnd@arndb.de>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Jonathan Corbet" <corbet@lwn.net>,
"Shuah Khan" <shuah@kernel.org>,
linux-kernel@vger.kernel.org, linux-api@vger.kernel.org,
wine-devel@winehq.org, "André Almeida" <andrealmeid@igalia.com>,
"Wolfram Sang" <wsa@kernel.org>,
"Arkadiusz Hiler" <ahiler@codeweavers.com>,
"Andy Lutomirski" <luto@kernel.org>,
linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org,
"Randy Dunlap" <rdunlap@infradead.org>,
"Ingo Molnar" <mingo@redhat.com>, "Will Deacon" <will@kernel.org>,
"Waiman Long" <longman@redhat.com>,
"Boqun Feng" <boqun.feng@gmail.com>
Subject: Re: [PATCH v4 00/30] NT synchronization primitive driver
Date: Tue, 16 Apr 2024 16:18:24 -0500 [thread overview]
Message-ID: <4340072.ejJDZkT8p0@terabithia> (raw)
In-Reply-To: <20240416081421.GB31647@noisy.programming.kicks-ass.net>
On Tuesday, 16 April 2024 03:14:21 CDT Peter Zijlstra wrote:
> On Mon, Apr 15, 2024 at 08:08:10PM -0500, Elizabeth Figura wrote:
> > This patch series implements a new char misc driver, /dev/ntsync, which is
> > used to implement Windows NT synchronization primitives.
>
> This patch series does not apply to anything I have at hand. Nor does it
> state anything explicit to put it on top of.
It was written to apply against the 'char-misc-next' branch of gregkh/char-
misc.git. I'll make a note of that next time, sorry for the inconvenience.
> > Hence I would like to request review from someone familiar with locking to
> > make sure that the usage of low-level kernel primitives is correct and
> > that the wait queues work as intended, and to that end I've CC'd the
> > locking maintainers.
> I am sadly very limited atm, but I'll try and read through it. If only I
> could apply...
>
> > == 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/27
> > 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/ntsync5
>
> I don't support GE has it in his builds? Last time I tried, building
> Wine was a bit of a pain.
It doesn't seem so. I tried to build a GE-compatible ntsync build, uploaded
here (thanks Arek for hosting):
https://f002.backblazeb2.com/file/wine-ntsync/ntsync-wine.tar.xz
> > Some aspects of the implementation may deserve particular comment:
> >
> > * In the interest of performance, each object is governed only by a single
> >
> > spinlock. However, NTSYNC_IOC_WAIT_ALL requires that the state of
> > multiple
> > objects be changed as a single atomic operation. In order to achieve
> > this, we first take a device-wide lock ("wait_all_lock") any time we
> > are going to lock more than one object at a time.
> >
> > The maximum number of objects that can be used in a vectored wait, and
> > therefore the maximum that can be locked simultaneously, is 64. This
> > number is NT's own limit.
> >
> > The acquisition of multiple spinlocks will degrade performance. This is
> > a
> > conscious choice, however. Wait-for-all is known to be a very rare
> > operation in practice, especially with counts that approach the
> > maximum, and it is the intent of the ntsync driver to optimize
> > wait-for-any at the expense of wait-for-all as much as possible.
>
> Per the example of percpu-rwsem, it would be possible to create a
> mutex-spinlock hybrid scheme, where single locks are spinlocks while
> held, but can block when the global thing is pending. And the global
> lock is always mutex like.
>
> If all that is worth it, I don't know. Nesting 64 spinlocks doesn't give
> me warm and fuzzy feelings though.
Is the concern about poor performance when ntsync is in use, or is nesting a
lot of spinlocks like that something that could cause problems for unrelated
tasks? I'm not familiar enough with the scheduler to know if this can be
abused.
I think we don't care about performance problems within Wine, at least. FWIW,
the scheme here is actually similar to what Windows does (as described by one
of their kernel engineers), although slightly different. NT nests spinlocks as
well, but instead of using the outer lock like our "wait_all_lock" to prevent
lock inversion, they instead sort the inner locks (by address, I assume).
If there's deeper problems... I can look into (ab)using a rwlock for this
purpose, at least for now.
In any case making wait_all_lock into a sleeping mutex instead of a spinlock
should be fine. I'll rerun performance tests but I don't expect it to cause
any problems.
next prev parent reply other threads:[~2024-04-16 21:18 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-16 1:08 [PATCH v4 00/30] NT synchronization primitive driver Elizabeth Figura
2024-04-16 1:08 ` [PATCH v4 01/27] ntsync: Introduce NTSYNC_IOC_WAIT_ANY Elizabeth Figura
2024-04-16 1:08 ` [PATCH v4 02/27] ntsync: Introduce NTSYNC_IOC_WAIT_ALL Elizabeth Figura
2024-04-17 11:37 ` Peter Zijlstra
2024-04-17 20:03 ` Elizabeth Figura
2024-04-18 9:35 ` Peter Zijlstra
2024-04-19 16:28 ` Peter Zijlstra
2024-05-14 4:15 ` Elizabeth Figura
2024-04-16 1:08 ` [PATCH v4 03/27] ntsync: Introduce NTSYNC_IOC_CREATE_MUTEX Elizabeth Figura
2024-04-16 1:08 ` [PATCH v4 04/27] ntsync: Introduce NTSYNC_IOC_MUTEX_UNLOCK Elizabeth Figura
2024-04-16 1:08 ` [PATCH v4 05/27] ntsync: Introduce NTSYNC_IOC_MUTEX_KILL Elizabeth Figura
2024-04-16 1:08 ` [PATCH v4 06/27] ntsync: Introduce NTSYNC_IOC_CREATE_EVENT Elizabeth Figura
2024-04-16 1:08 ` [PATCH v4 07/27] ntsync: Introduce NTSYNC_IOC_EVENT_SET Elizabeth Figura
2024-04-16 1:08 ` [PATCH v4 08/27] ntsync: Introduce NTSYNC_IOC_EVENT_RESET Elizabeth Figura
2024-04-16 1:08 ` [PATCH v4 09/27] ntsync: Introduce NTSYNC_IOC_EVENT_PULSE Elizabeth Figura
2024-04-16 1:08 ` [PATCH v4 10/27] ntsync: Introduce NTSYNC_IOC_SEM_READ Elizabeth Figura
2024-04-16 1:08 ` [PATCH v4 11/27] ntsync: Introduce NTSYNC_IOC_MUTEX_READ Elizabeth Figura
2024-04-16 1:08 ` [PATCH v4 12/27] ntsync: Introduce NTSYNC_IOC_EVENT_READ Elizabeth Figura
2024-04-16 1:08 ` [PATCH v4 13/27] ntsync: Introduce alertable waits Elizabeth Figura
2024-04-16 1:08 ` [PATCH v4 14/27] selftests: ntsync: Add some tests for semaphore state Elizabeth Figura
2024-04-16 1:08 ` [PATCH v4 15/27] selftests: ntsync: Add some tests for mutex state Elizabeth Figura
2024-04-16 1:08 ` [PATCH v4 16/27] selftests: ntsync: Add some tests for NTSYNC_IOC_WAIT_ANY Elizabeth Figura
2024-04-16 1:08 ` [PATCH v4 17/27] selftests: ntsync: Add some tests for NTSYNC_IOC_WAIT_ALL Elizabeth Figura
2024-04-16 1:08 ` [PATCH v4 18/27] selftests: ntsync: Add some tests for wakeup signaling with WINESYNC_IOC_WAIT_ANY Elizabeth Figura
2024-04-16 1:08 ` [PATCH v4 19/27] selftests: ntsync: Add some tests for wakeup signaling with WINESYNC_IOC_WAIT_ALL Elizabeth Figura
2024-04-16 1:08 ` [PATCH v4 20/27] selftests: ntsync: Add some tests for manual-reset event state Elizabeth Figura
2024-04-16 1:08 ` [PATCH v4 21/27] selftests: ntsync: Add some tests for auto-reset " Elizabeth Figura
2024-04-16 1:08 ` [PATCH v4 22/27] selftests: ntsync: Add some tests for wakeup signaling with events Elizabeth Figura
2024-04-16 1:08 ` [PATCH v4 23/27] selftests: ntsync: Add tests for alertable waits Elizabeth Figura
2024-04-16 1:08 ` [PATCH v4 24/27] selftests: ntsync: Add some tests for wakeup signaling via alerts Elizabeth Figura
2024-04-16 1:08 ` [PATCH v4 25/27] selftests: ntsync: Add a stress test for contended waits Elizabeth Figura
2024-04-16 1:08 ` [PATCH v4 26/27] maintainers: Add an entry for ntsync Elizabeth Figura
2024-04-16 1:08 ` [PATCH v4 27/27] docs: ntsync: Add documentation for the ntsync uAPI Elizabeth Figura
2024-04-16 2:13 ` Randy Dunlap
2024-04-16 8:14 ` [PATCH v4 00/30] NT synchronization primitive driver Peter Zijlstra
2024-04-16 8:49 ` Greg Kroah-Hartman
2024-04-16 15:50 ` Peter Zijlstra
2024-04-16 15:53 ` Peter Zijlstra
2024-04-16 16:19 ` Peter Zijlstra
2024-04-16 21:18 ` Elizabeth Figura
2024-04-17 5:21 ` Peter Zijlstra
2024-04-16 21:18 ` Elizabeth Figura [this message]
2024-04-16 22:18 ` Elizabeth Figura
2024-04-19 16:16 ` Peter Zijlstra
2024-04-19 20:46 ` Elizabeth Figura
2024-05-07 0:40 ` Elizabeth Figura
2024-05-07 0:50 ` Elizabeth Figura
2024-04-17 5:24 ` Peter Zijlstra
2024-04-16 16:05 ` Peter Zijlstra
2024-04-16 21:18 ` Elizabeth Figura
2024-04-17 5:22 ` Peter Zijlstra
2024-04-17 6:05 ` Elizabeth Figura
2024-04-17 10:01 ` Peter Zijlstra
2024-04-17 20:02 ` Elizabeth Figura
2024-05-15 23:32 ` Elizabeth Figura
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4340072.ejJDZkT8p0@terabithia \
--to=zfigura@codeweavers.com \
--cc=ahiler@codeweavers.com \
--cc=andrealmeid@igalia.com \
--cc=arnd@arndb.de \
--cc=boqun.feng@gmail.com \
--cc=corbet@lwn.net \
--cc=gregkh@linuxfoundation.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=longman@redhat.com \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rdunlap@infradead.org \
--cc=shuah@kernel.org \
--cc=will@kernel.org \
--cc=wine-devel@winehq.org \
--cc=wsa@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).