[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1453411389.30844.38.camel@schen9-desk2.jf.intel.com>
Date: Thu, 21 Jan 2016 13:23:09 -0800
From: Tim Chen <tim.c.chen@...ux.intel.com>
To: Ding Tianhong <dingtianhong@...wei.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Davidlohr Bueso <dave@...olabs.net>,
Linus Torvalds <torvalds@...ux-foundation.org>,
"Paul E. McKenney" <paulmck@...ibm.com>,
Thomas Gleixner <tglx@...utronix.de>,
Will Deacon <Will.Deacon@....com>,
Jason Low <jason.low2@...com>, Waiman Long <Waiman.Long@...com>
Subject: Re: [PATCH RFC] locking/mutexes: don't spin on owner when wait list
is not NULL.
On Thu, 2016-01-21 at 17:29 +0800, Ding Tianhong wrote:
>
> diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
> index 0551c21..596b341 100644
> --- a/kernel/locking/mutex.c
> +++ b/kernel/locking/mutex.c
> @@ -256,7 +256,7 @@ static inline int mutex_can_spin_on_owner(struct mutex *lock)
> struct task_struct *owner;
> int retval = 1;
>
> - if (need_resched())
> + if (need_resched() || atomic_read(&lock->count) == -1)
> return 0;
>
One concern I have is this change will eliminate any optimistic spinning
as long as there is a waiter. Is there a middle ground that we
can allow only one spinner if there are waiters?
In other words, we allow spinning when
atomic_read(&lock->count) == -1 but there is no one on the
osq lock that queue up the spinners (i.e. no other process doing
optimistic spinning).
This could allow a bit of spinning without starving out the waiters.
Tim
Powered by blists - more mailing lists