Re: [PATCH] microoptimize by trying to avoid locking a locked mutex

2015-11-06 Thread Hans Petter Selasky
On 11/06/15 01:55, Mateusz Guzik wrote: On Thu, Nov 05, 2015 at 04:35:22PM -0700, Ian Lepore wrote: On Thu, 2015-11-05 at 14:19 -0800, John Baldwin wrote: On Thursday, November 05, 2015 01:45:19 PM Adrian Chadd wrote: On 5 November 2015 at 11:26, Mateusz Guzik wrote: On Thu, Nov 05, 2015 at

Re: [PATCH] microoptimize by trying to avoid locking a locked mutex

2015-11-06 Thread David Chisnall
On 5 Nov 2015, at 16:55, Mateusz Guzik wrote: > >> Will that cause problems, especially for code inside a loop >> where the compiler may decide to shuffle things around? >> > > Lock value is volatile, so the compiler should not screw us up. Note: volatile means do not reorder loads/stores *to

Re: [PATCH] microoptimize by trying to avoid locking a locked mutex

2015-11-05 Thread John Baldwin
On Thursday, November 05, 2015 04:35:22 PM Ian Lepore wrote: > On Thu, 2015-11-05 at 14:19 -0800, John Baldwin wrote: > > On Thursday, November 05, 2015 01:45:19 PM Adrian Chadd wrote: > > > On 5 November 2015 at 11:26, Mateusz Guzik > > > wrote: > > > > On Thu, Nov 05, 2015 at 11:04:13AM -0800, J

Re: [PATCH] microoptimize by trying to avoid locking a locked mutex

2015-11-05 Thread Mateusz Guzik
On Thu, Nov 05, 2015 at 04:35:22PM -0700, Ian Lepore wrote: > On Thu, 2015-11-05 at 14:19 -0800, John Baldwin wrote: > > On Thursday, November 05, 2015 01:45:19 PM Adrian Chadd wrote: > > > On 5 November 2015 at 11:26, Mateusz Guzik > > > wrote: > > > > On Thu, Nov 05, 2015 at 11:04:13AM -0800, Jo

Re: [PATCH] microoptimize by trying to avoid locking a locked mutex

2015-11-05 Thread Ian Lepore
On Thu, 2015-11-05 at 14:19 -0800, John Baldwin wrote: > On Thursday, November 05, 2015 01:45:19 PM Adrian Chadd wrote: > > On 5 November 2015 at 11:26, Mateusz Guzik > > wrote: > > > On Thu, Nov 05, 2015 at 11:04:13AM -0800, John Baldwin wrote: > > > > On Thursday, November 05, 2015 04:26:28 PM K

Re: [PATCH] microoptimize by trying to avoid locking a locked mutex

2015-11-05 Thread John Baldwin
On Thursday, November 05, 2015 01:45:19 PM Adrian Chadd wrote: > On 5 November 2015 at 11:26, Mateusz Guzik wrote: > > On Thu, Nov 05, 2015 at 11:04:13AM -0800, John Baldwin wrote: > >> On Thursday, November 05, 2015 04:26:28 PM Konstantin Belousov wrote: > >> > On Thu, Nov 05, 2015 at 12:32:18AM

Re: [PATCH] microoptimize by trying to avoid locking a locked mutex

2015-11-05 Thread Adrian Chadd
On 5 November 2015 at 11:26, Mateusz Guzik wrote: > On Thu, Nov 05, 2015 at 11:04:13AM -0800, John Baldwin wrote: >> On Thursday, November 05, 2015 04:26:28 PM Konstantin Belousov wrote: >> > On Thu, Nov 05, 2015 at 12:32:18AM +0100, Mateusz Guzik wrote: >> > > mtx_lock will unconditionally try to

Re: [PATCH] microoptimize by trying to avoid locking a locked mutex

2015-11-05 Thread Mateusz Guzik
On Thu, Nov 05, 2015 at 11:04:13AM -0800, John Baldwin wrote: > On Thursday, November 05, 2015 04:26:28 PM Konstantin Belousov wrote: > > On Thu, Nov 05, 2015 at 12:32:18AM +0100, Mateusz Guzik wrote: > > > mtx_lock will unconditionally try to grab the lock and if that fails, > > > will call __mtx_

Re: [PATCH] microoptimize by trying to avoid locking a locked mutex

2015-11-05 Thread John Baldwin
On Thursday, November 05, 2015 04:26:28 PM Konstantin Belousov wrote: > On Thu, Nov 05, 2015 at 12:32:18AM +0100, Mateusz Guzik wrote: > > mtx_lock will unconditionally try to grab the lock and if that fails, > > will call __mtx_lock_sleep which will immediately try to do the same > > atomic op aga

Re: [PATCH] microoptimize by trying to avoid locking a locked mutex

2015-11-05 Thread Konstantin Belousov
On Thu, Nov 05, 2015 at 12:32:18AM +0100, Mateusz Guzik wrote: > mtx_lock will unconditionally try to grab the lock and if that fails, > will call __mtx_lock_sleep which will immediately try to do the same > atomic op again. > > So, the obvious microoptimization is to check the state in > __mtx_lo

Re: [PATCH] microoptimize by trying to avoid locking a locked mutex

2015-11-04 Thread Hans Petter Selasky
Hi, Did you test this patch works like expected with non x86 platforms? --HPS On 11/05/15 00:32, Mateusz Guzik wrote: mtx_lock will unconditionally try to grab the lock and if that fails, will call __mtx_lock_sleep which will immediately try to do the same atomic op again. So, the obvious mic