Re: [PATCH 3/5] ipc/sem: optimize perform_atomic_semop()

2016-09-18 Thread Manfred Spraul
Hi Davidlohr, On 09/13/2016 10:33 AM, Davidlohr Bueso wrote: @@ -1751,12 +1820,17 @@ SYSCALL_DEFINE4(semtimedop, int, semid, struct sembuf __user *, tsops, if (sop->sem_num >= max) max = sop->sem_num; if (sop->sem_flg & SEM_UNDO) -undos = 1; +

[PATCH 3/5] ipc/sem: optimize perform_atomic_semop()

2016-09-18 Thread Davidlohr Bueso
This is the main workhorse that deals with semop user calls such that the waitforzero or semval update operations, on the set, can complete on not as the sma currently stands. Currently, the set is iterated twice (setting semval, then backwards for the sempid value). Slowpaths, and particularly SEM

Re: [PATCH 3/5] ipc/sem: optimize perform_atomic_semop()

2016-09-13 Thread Davidlohr Bueso
On Mon, 12 Sep 2016, Manfred Spraul wrote: This patch proposes still iterating the set twice, but the first scan is read-only, and we perform the actual updates afterward, once we know that the call will succeed. In order to not suffer from the overhead of dealing with sops that act on the same

Re: [PATCH 3/5] ipc/sem: optimize perform_atomic_semop()

2016-09-12 Thread Manfred Spraul
Hi Davidlohr, On 09/12/2016 01:53 PM, Davidlohr Bueso wrote: This is the main workhorse that deals with semop user calls such that the waitforzero or semval update operations, on the set, can complete on not as the sma currently stands. Currently, the set is iterated twice (setting semval, then

[PATCH 3/5] ipc/sem: optimize perform_atomic_semop()

2016-09-12 Thread Davidlohr Bueso
This is the main workhorse that deals with semop user calls such that the waitforzero or semval update operations, on the set, can complete on not as the sma currently stands. Currently, the set is iterated twice (setting semval, then backwards for the sempid value). Slowpaths, and particularly SEM