On 08/14/2014 01:30 PM, Davidlohr Bueso wrote:
On Thu, 2014-08-14 at 13:17 -0400, Waiman Long wrote:
I still think it is better to do that after spin_lock_mutex().
As mentioned, this causes all sorts of hung tasks when the another task
enters the slowpath when locking. There's a big fat commen
On Thu, 2014-08-14 at 13:17 -0400, Waiman Long wrote:
> On 08/14/2014 01:57 AM, Davidlohr Bueso wrote:
> > Mutexes lock-stealing functionality allows another task to
> > skip its turn in the wait-queue and atomically acquire the lock.
> > This is fine and a nice optimization, however, when releasin
On 08/14/2014 01:57 AM, Davidlohr Bueso wrote:
Mutexes lock-stealing functionality allows another task to
skip its turn in the wait-queue and atomically acquire the lock.
This is fine and a nice optimization, however, when releasing
the mutex, we always wakeup the next task in FIFO order. When
th
Mutexes lock-stealing functionality allows another task to
skip its turn in the wait-queue and atomically acquire the lock.
This is fine and a nice optimization, however, when releasing
the mutex, we always wakeup the next task in FIFO order. When
the lock has been stolen, this leads to wasting wak
4 matches
Mail list logo
