On 08/10/2014 07:50 PM, Davidlohr Bueso wrote:
On Sun, 2014-08-10 at 17:41 -0400, Waiman Long wrote:
On 08/08/2014 03:03 PM, Davidlohr Bueso wrote:
On Fri, 2014-08-08 at 14:30 -0400, Waiman Long wrote:
I have 2 issues about this. First of all, the timing windows between
atomic_set() and mutex_
On Sun, 2014-08-10 at 17:41 -0400, Waiman Long wrote:
> On 08/08/2014 03:03 PM, Davidlohr Bueso wrote:
> > On Fri, 2014-08-08 at 14:30 -0400, Waiman Long wrote:
> >> I have 2 issues about this. First of all, the timing windows between
> >> atomic_set() and mutex_has_owner() check is really small, I
On 08/08/2014 04:38 PM, Jason Low wrote:
On Fri, 2014-08-08 at 13:21 -0700, Davidlohr Bueso wrote:
On Fri, 2014-08-08 at 12:50 -0700, Jason Low wrote:
__visible __used noinline
@@ -730,6 +744,23 @@ __mutex_unlock_common_slowpath(struct mutex *lock, int
nested)
if (__mutex_slowpath_ne
On 08/08/2014 03:03 PM, Davidlohr Bueso wrote:
On Fri, 2014-08-08 at 14:30 -0400, Waiman Long wrote:
I have 2 issues about this. First of all, the timing windows between
atomic_set() and mutex_has_owner() check is really small, I doubt it
will be that effective.
That is true, which is why I did
On Fri, 2014-08-08 at 13:21 -0700, Davidlohr Bueso wrote:
> On Fri, 2014-08-08 at 12:50 -0700, Jason Low wrote:
> > > __visible __used noinline
> > > @@ -730,6 +744,23 @@ __mutex_unlock_common_slowpath(struct mutex *lock,
> > > int nested)
> > > if (__mutex_slowpath_needs_to_unlock())
> > >
On Fri, 2014-08-08 at 12:50 -0700, Jason Low wrote:
> > __visible __used noinline
> > @@ -730,6 +744,23 @@ __mutex_unlock_common_slowpath(struct mutex *lock, int
> > nested)
> > if (__mutex_slowpath_needs_to_unlock())
> > atomic_set(&lock->count, 1);
> >
> > +/*
> > + * Skipping
> __visible __used noinline
> @@ -730,6 +744,23 @@ __mutex_unlock_common_slowpath(struct mutex *lock, int
> nested)
> if (__mutex_slowpath_needs_to_unlock())
> atomic_set(&lock->count, 1);
>
> +/*
> + * Skipping the mutex_has_owner() check when DEBUG, allows us to
> + * avo
On Fri, 2014-08-08 at 14:30 -0400, Waiman Long wrote:
> I have 2 issues about this. First of all, the timing windows between
> atomic_set() and mutex_has_owner() check is really small, I doubt it
> will be that effective.
That is true, which is why I didn't bother showing any performance data
i
On 08/08/2014 01:39 AM, Davidlohr Bueso wrote:
On Thu, 2014-08-07 at 17:45 -0700, Davidlohr Bueso wrote:
On Thu, 2014-08-07 at 18:26 -0400, Waiman Long wrote:
On a highly contended rwsem, spinlock contention due to the slow
rwsem_wake() call can be a significant portion of the total CPU cycles
On Thu, 2014-08-07 at 17:45 -0700, Davidlohr Bueso wrote:
> On Thu, 2014-08-07 at 18:26 -0400, Waiman Long wrote:
> > On a highly contended rwsem, spinlock contention due to the slow
> > rwsem_wake() call can be a significant portion of the total CPU cycles
> > used. With writer lock stealing and w
On Thu, 2014-08-07 at 18:26 -0400, Waiman Long wrote:
> On a highly contended rwsem, spinlock contention due to the slow
> rwsem_wake() call can be a significant portion of the total CPU cycles
> used. With writer lock stealing and writer optimistic spinning, there
> is also a pretty good chance th
On a highly contended rwsem, spinlock contention due to the slow
rwsem_wake() call can be a significant portion of the total CPU cycles
used. With writer lock stealing and writer optimistic spinning, there
is also a pretty good chance that the lock may have been stolen
before the waker wakes up the
12 matches
Mail list logo
