Messages in this thread | | | Subject | Re: [PATCH 0/2] ipc/sem.c: sem_lock fixes | From | Manfred Spraul <> | Date | Thu, 14 Jul 2016 18:40:08 +0200 |
| |
Hi Andrew,
On 07/14/2016 12:05 AM, Andrew Morton wrote: > On Wed, 13 Jul 2016 07:06:50 +0200 Manfred Spraul <manfred@colorfullife.com> wrote: > >> Hi Andrew, Hi Peter, >> >> next version of the sem_lock() fixes: >> The patches are again vs. tip. >> >> Patch 1 is ready for merging, Patch 2 is for review. >> >> - Patch 1 is the patch as in -next since January >> It fixes the race that was found by Felix. >> - Patch 2 removes the memory barriers that are part of the qspinlock >> code. >> - (The hysteresis patch would be patch 3. The risk of regressions >> can't be ruled out, thus it must wait for benchmarks from real >> workload tests) > I think you're saying that if these two patches cause performance > regressions, we will need ipc-sem-sem_lock-with-hysteresis.patch? No, the two patches will not cause any regressions.
Commit 6062a8dc051 ("ipc,sem: fine grained locking for semtimedop") was a huge scalability improvement for 99% of the users, but introduced a regression for one workload. Noone complained about it, so the workload must be rare. Patch 3 now fixes the regression. But we live with the introduced regression for 3 years, so give me (and Davidlohr, and anyone else who wants to support) some more time. Also on my TODO list: The queue merge/unmerge logic, i.e. commit f269f40ad5ae ("ipc/sem.c: always use only one queue for alter operations") might also win from some hysteresis.
My proposal: - patch 1: merge towards main tree. - patch 2: needs update. The barrier in sem_lock() is required. I'm not yet sure about complexmode_enter(), perhaps with #ifndef CONFIG_QUEUED_SPINLOCKS - patch 3 should wait.
--
Manfred
| |