Messages in this thread |  | | | Date | Tue, 7 Jun 2011 22:10:55 +0800 | | Subject | Re: [PATCH] sched: correct testing need_resched in mutex_spin_on_owner() | | From | Hillf Danton <> |
| |
On Tue, Jun 7, 2011 at 9:47 PM, Peter Zijlstra <peterz@infradead.org> wrote: > On Tue, 2011-06-07 at 21:41 +0800, Hillf Danton wrote: >> It is suppose to check the owner task that is not absolutly running on the >> local CPU, > > Oh, why do you think so? > as the comment in __mutex_lock_common() says,
#ifdef CONFIG_MUTEX_SPIN_ON_OWNER /* * Optimistic spinning. * * We try to spin for acquisition when we find that there are no * pending waiters and the lock owner is currently running on a *************************** * (different) CPU. *************************** * ..... */ >> and if NEED_RESCHED is happenly set on the current task of local >> CPU, we get incorrect result. > > Only if your above assumption holds, which it doesn't. It explicitly > checks to see if _this_ cpu needs a resched while spinning, if so it > bails the spinning and calls schedule in the lock slow path. > > If the owner cpu reschedules, owner will leave the rq and > owner_running() will return false, also breaking the loop. >
need_resched is checked after true is returned by owner_running(), in other words, owner is still on its CPU, so owner should be check here. Even ower's CPU == this CPU, checking owner also gives correct result.
thanks Hillf
|  |