[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1466876272-3824-1-git-send-email-manfred@colorfullife.com>
Date: Sat, 25 Jun 2016 19:37:50 +0200
From: Manfred Spraul <manfred@...orfullife.com>
To: "H. Peter Anvin" <hpa@...or.com>,
Peter Zijlstra <peterz@...radead.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Davidlohr Bueso <dave@...olabs.net>
Cc: LKML <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...e.hu>, 1vier1@....de,
felixh@...ormatik.uni-bremen.de,
Manfred Spraul <manfred@...orfullife.com>
Subject: [PATCH 0/2] ipc/sem.c: sem_lock fixes
Hi Andrew, Hi Peter,
next version of the sem_lock() fixes / improvement:
The patches are now vs. tip.
Patch 1 is ready for merging, patch 2 is new and for discussion.
Patch 1 fixes the race that was found by Felix.
It also adds smp_mb() to fully synchronize
WRITE_ONCE(status, 1);
<<< smp_mb();
spin_unlock_wait();
vs.
spin_lock();
<<< smp_mb();
READ_ONCE(status);
Patch 2 tries to close a performance regression:
sem_wait_array() must perform a spin_unlock_wait() for every
semaphore in the array. If the array is large, then this is
slow.
Two open points:
- Do we need it? Factor 20 improvement is nice, but is the
test realistic?
- COMPLEX_MODE_ENTER=10 is a magic number, without any
rational. (2+sem_nsems/128) would be another option,
but also arbitrary.
Test:
https://github.com/manfred-colorfu/ipcscale
# ./sem-scalebench -o 4 -f -m 0 -h 4 -i 1 -p 2 -c 8 -t 5 -d 500
Before: 214732
After: 4008635
--
Manfred
Powered by blists - more mailing lists