diff options
author | Martin Schwidefsky | 2017-03-24 17:32:23 +0100 |
---|---|---|
committer | Martin Schwidefsky | 2017-09-28 07:29:44 +0200 |
commit | eb3b7b848fb3dd00f7a57d633d4ae4d194aa7865 (patch) | |
tree | ab510aeb7e5aedc07d1cd0e60c5d430c74e02bd8 /arch/hexagon/Kconfig | |
parent | s390/spinlock: introduce spinlock wait queueing (diff) | |
download | kernel-qcow2-linux-eb3b7b848fb3dd00f7a57d633d4ae4d194aa7865.tar.gz kernel-qcow2-linux-eb3b7b848fb3dd00f7a57d633d4ae4d194aa7865.tar.xz kernel-qcow2-linux-eb3b7b848fb3dd00f7a57d633d4ae4d194aa7865.zip |
s390/rwlock: introduce rwlock wait queueing
Like the common queued rwlock code the s390 implementation uses the
queued spinlock code on a spinlock_t embedded in the rwlock_t to achieve
the queueing. The encoding of the rwlock_t differs though, the counter
field in the rwlock_t is split into two parts. The upper two bytes hold
the write bit and the write wait counter, the lower two bytes hold the
read counter.
The arch_read_lock operation works exactly like the common qrwlock but
the enqueue operation for a writer follows a diffent logic. After the
failed inline try to get the rwlock in write, the writer first increases
the write wait counter, acquires the wait spin_lock for the queueing,
and then loops until there are no readers and the write bit is zero.
Without the write wait counter a CPU that just released the rwlock
could immediately reacquire the lock in the inline code, bypassing all
outstanding read and write waiters. For s390 this would cause massive
imbalances in favour of writers in case of a contended rwlock.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Diffstat (limited to 'arch/hexagon/Kconfig')
0 files changed, 0 insertions, 0 deletions