History log of /freebsd/sys/kern/kern_sx.c (Results 26 – 50 of 337)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: release/12.1.0, release/11.3.0
# 67350cb5 09-Dec-2018 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r340918 through r341763.


Revision tags: release/12.0.0
# f26db694 05-Dec-2018 Mateusz Guzik <mjg@FreeBSD.org>

sx: retire SX_NOADAPTIVE

The flag is not used by anything for years and supporting it requires an
explicit read from the lock when entering slow path.

Flag value is left unused on purpose.

Sponsor

sx: retire SX_NOADAPTIVE

The flag is not used by anything for years and supporting it requires an
explicit read from the lock when entering slow path.

Flag value is left unused on purpose.

Sponsored by: The FreeBSD Foundation

show more ...


# 6149ed01 14-Nov-2018 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r340368 through r340426.


# d54474e6 13-Nov-2018 Eric van Gyzen <vangyzen@FreeBSD.org>

Make no assertions about lock state when the scheduler is stopped.

Change the assert paths in rm, rw, and sx locks to match the lock
and unlock paths. I did this for mutexes in r306346.

Reported b

Make no assertions about lock state when the scheduler is stopped.

Change the assert paths in rm, rw, and sx locks to match the lock
and unlock paths. I did this for mutexes in r306346.

Reported by: Travis Lane <tlane@isilon.com>
MFC after: 2 weeks
Sponsored by: Dell EMC Isilon

show more ...


Revision tags: release/11.2.0
# ee252fc9 22-May-2018 Mateusz Guzik <mjg@FreeBSD.org>

sx: fixup a braino in r334024

If a thread waiting on sx dropped Giant it would not be properly
reacquired on exit from the routine, later resulting in panics
indicating Giant is not held (when it sh

sx: fixup a braino in r334024

If a thread waiting on sx dropped Giant it would not be properly
reacquired on exit from the routine, later resulting in panics
indicating Giant is not held (when it should be).

The bug was not present in the original patch sent to pho, I wittingly
added it just prior to the commit and only smoke-tested it.

Reported by: pho

show more ...


# 2466d12b 22-May-2018 Mateusz Guzik <mjg@FreeBSD.org>

sx: port over writer starvation prevention measures from rwlock

A constant stream of readers could completely starve writers and this is not
a hypothetical scenario.

The 'poll2_threads' test from t

sx: port over writer starvation prevention measures from rwlock

A constant stream of readers could completely starve writers and this is not
a hypothetical scenario.

The 'poll2_threads' test from the will-it-scale suite reliably starves writers
even with concurrency < 10 threads.

The problem was run into and diagnosed by dillon@backplane.com

There was next to no change in lock contention profile during -j 128 pkg build,
despite an sx lock being at the top.

Tested by: pho

show more ...


# 1dce110f 19-May-2018 Matt Macy <mmacy@FreeBSD.org>

fix uninitialized variable warning in reader locks


# e0e259a8 11-Apr-2018 Mateusz Guzik <mjg@FreeBSD.org>

locks: extend speculative spin waiting for readers to drain

Now that 10 years have passed since the original limit of 10000 was
committed, bump it a little bit.

Spinning waiting for writers is semi

locks: extend speculative spin waiting for readers to drain

Now that 10 years have passed since the original limit of 10000 was
committed, bump it a little bit.

Spinning waiting for writers is semi-informed in the sense that we always
know if the owner is running and base the decision to spin on that.
However, no such information is provided for read-locking. In particular
this means that it is possible for a write-spinner to completely waste cpu
time waiting for the lock to be released, while the reader holding it was
preempted and is now waiting for the spinner to go off cpu.

Nonetheless, in majority of cases it is an improvement to spin instead of
instantly giving up and going to sleep.

The current approach is pretty simple: snatch the number of current readers
and performs that many pauses before checking again. The total number of
pauses to execute is limited to 10k. If the lock is still not free by
that time, go to sleep.

Given the previously noted problem of not knowing whether spinning makes
any sense to begin with the new limit has to remain rather conservative.
But at the very least it should also be related to the machine. Waiting
for writers uses parameters selected based on the number of activated
hardware threads. The upper limit of pause instructions to be executed
in-between re-reads of the lock is typically 16384 or 32678. It was
selected as the limit of total spins. The lower bound is set to
already present 10000 as to not change it for smaller machines.

Bumping the limit reduces system time by few % during benchmarks like
buildworld, buildkernel and others. Tested on 2 and 4 socket machines
(Broadwell, Skylake).

Figuring out how to make a more informed decision while not pessimizing
the fast path is left as an exercise for the reader.

show more ...


# 09bdec20 17-Mar-2018 Mateusz Guzik <mjg@FreeBSD.org>

locks: slightly depessimize lockstat

The slow path is always taken when lockstat is enabled. This induces
rdtsc (or other) calls to get the cycle count even when there was no
contention.

Still go t

locks: slightly depessimize lockstat

The slow path is always taken when lockstat is enabled. This induces
rdtsc (or other) calls to get the cycle count even when there was no
contention.

Still go to the slow path to not mess with the fast path, but avoid
the heavy lifting unless necessary.

This reduces sys and real time during -j 80 buildkernel:
before: 3651.84s user 1105.59s system 5394% cpu 1:28.18 total
after: 3685.99s user 975.74s system 5450% cpu 1:25.53 total
disabled: 3697.96s user 411.13s system 5261% cpu 1:18.10 total

So note this is still a significant hit.

LOCK_PROFILING results are not affected.

show more ...


# a8e747c5 04-Mar-2018 Mateusz Guzik <mjg@FreeBSD.org>

sx: don't do an atomic op in upgrade if it cananot succeed

The code already pays the cost of reading the lock to obtain the waiters
flag. Checking whether there is more than one reader is not a prob

sx: don't do an atomic op in upgrade if it cananot succeed

The code already pays the cost of reading the lock to obtain the waiters
flag. Checking whether there is more than one reader is not a problem and
avoids dirtying the line.

This also fixes a small corner case: if waiters were to show up between
reading the flag and upgrading the lock, the operation would fail even
though it should not. No correctness change here though.

show more ...


# d94df98c 04-Mar-2018 Mateusz Guzik <mjg@FreeBSD.org>

locks: fix a corner case in r327399

If there were exactly rowner_retries/asx_retries (by default: 10) transitions
between read and write state and the waiters still did not get the lock, the
next ow

locks: fix a corner case in r327399

If there were exactly rowner_retries/asx_retries (by default: 10) transitions
between read and write state and the waiters still did not get the lock, the
next owner -> reader transition would result in the code correctly falling
back to turnstile/sleepq where it would incorrectly think it was waiting
for a writer and decide to leave turnstile/sleepq to loop back. From this
point it would take ts/sq trips until the lock gets released.

The bug sometimes manifested itself in stalls during -j 128 package builds.

Refactor the code to fix the bug, while here remove some of the gratituous
differences between rw and sx locks.

show more ...


# c505b599 02-Mar-2018 Mateusz Guzik <mjg@FreeBSD.org>

sx: fix adaptive spinning broken in r327397

The condition was flipped.

In particular heavy multithreaded kernel builds on zfs started suffering
due to nested sx locks.

For instance make -s -j 128

sx: fix adaptive spinning broken in r327397

The condition was flipped.

In particular heavy multithreaded kernel builds on zfs started suffering
due to nested sx locks.

For instance make -s -j 128 buildkernel:

before: 3326.67s user 1269.62s system 6981% cpu 1:05.84 total
after: 3365.55s user 911.27s system 6871% cpu 1:02.24 total

ps.
.-'---`-. .-'---`-.
,' `. ,' `.
| \ | \
| \ | \
\ _ \ \ _ \
,\ _ ,'-,/-)\ ,\ _ ,'-,/-)\
( * \ \,' ,' ,'-) ( * \ \,' ,' ,'-)
`._,) -',-') `._,) -',-')
\/ ''/ \/ ''/
) / / ) / /
/ ,'-' / ,'-'

show more ...


# e4ccf57f 17-Feb-2018 Mateusz Guzik <mjg@FreeBSD.org>

Undo LOCK_PROFILING pessimisation after r313454 and r313455

With the option used to compile the kernel both sx and rw shared ops would
always go to the slow path which added avoidable overhead even

Undo LOCK_PROFILING pessimisation after r313454 and r313455

With the option used to compile the kernel both sx and rw shared ops would
always go to the slow path which added avoidable overhead even when the
facility is disabled.

Furthermore the increased time spent doing uncontested shared lock acquire
would be bogusly added to total wait time, somewhat skewing the results.

Restore old behaviour of going there only when profiling is enabled.

This change is a no-op for kernels without LOCK_PROFILING (which is the
default).

show more ...


# 72bfb31a 13-Jan-2018 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r327886 through r327930.


# 1b54ffc8 13-Jan-2018 Mateusz Guzik <mjg@FreeBSD.org>

sx: retry hard shared unlock just like in r327905 for rwlocks


# 4b49587c 06-Jan-2018 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r327341 through r327623.


# efa9f177 31-Dec-2017 Mateusz Guzik <mjg@FreeBSD.org>

locks: adjust loop limit check when waiting for readers

The check was for the exact value, but since the counter started being
incremented by the number of readers it could have jumped over.


# cde25ed4 31-Dec-2017 Mateusz Guzik <mjg@FreeBSD.org>

sx: fix up non-smp compilation after r327397


# 28f1a9e3 31-Dec-2017 Mateusz Guzik <mjg@FreeBSD.org>

locks: re-check the reason to go to sleep after locking sleepq/turnstile

In both rw and sx locks we always go to sleep if the lock owner is not
running.

We do spin for some time if the lock is read

locks: re-check the reason to go to sleep after locking sleepq/turnstile

In both rw and sx locks we always go to sleep if the lock owner is not
running.

We do spin for some time if the lock is read-locked.

However, if we decide to go to sleep due to the lock owner being off cpu
and after sleepq/turnstile gets acquired the lock is read-locked, we should
fallback to the aforementioned wait.

show more ...


# fb106123 31-Dec-2017 Mateusz Guzik <mjg@FreeBSD.org>

sx: read the SX_NOADAPTIVE flag and Giant ownership only once

These used to be read multiple times when waiting for the lock the become
free, which had the potential to issue completely avoidable tr

sx: read the SX_NOADAPTIVE flag and Giant ownership only once

These used to be read multiple times when waiting for the lock the become
free, which had the potential to issue completely avoidable traffic.

show more ...


# 8a36da99 27-Nov-2017 Pedro F. Giffuni <pfg@FreeBSD.org>

sys/kern: adoption of SPDX licensing ID tags.

Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
prone

sys/kern: adoption of SPDX licensing ID tags.

Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
prone - task.

The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.

show more ...


# cec17473 25-Nov-2017 Mateusz Guzik <mjg@FreeBSD.org>

sx: change sunlock to wake waiters up if it locked sleepq

sleepq is only locked if the curhtread is the last reader. By the time
the lock gets acquired new ones could have arrived. The previous code

sx: change sunlock to wake waiters up if it locked sleepq

sleepq is only locked if the curhtread is the last reader. By the time
the lock gets acquired new ones could have arrived. The previous code
would unlock and loop back. This results spurious relocking of sleepq.

This is a step towards xadd-based unlock routine.

show more ...


# 93118b62 25-Nov-2017 Mateusz Guzik <mjg@FreeBSD.org>

locks: retry turnstile/sleepq loops on failed cmpset

In order to go to sleep threads set waiter flags, but that can spuriously
fail e.g. when a new reader arrives. Instead of unlocking everything an

locks: retry turnstile/sleepq loops on failed cmpset

In order to go to sleep threads set waiter flags, but that can spuriously
fail e.g. when a new reader arrives. Instead of unlocking everything and
looping back, re-evaluate the new state while still holding the lock necessary
to go to sleep.

show more ...


# dbe4541d 24-Nov-2017 Mark Johnston <markj@FreeBSD.org>

Have lockstat:::sx-release fire only after the lock state has changed.

MFC after: 1 week


# 26d94f99 24-Nov-2017 Mark Johnston <markj@FreeBSD.org>

Add a missing lockstat:::sx-downgrade probe.

We were returning without firing the probe when the lock had no shared
waiters.

MFC after: 1 week


12345678910>>...14