lkml.org 
[lkml]   [2012]   [Apr]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: semaphore and mutex in current Linux kernel (3.2.2)
On Wed, Apr 11, 2012 at 05:04:03AM +0000, Chen, Dennis (SRDC SW) wrote:
> On Tue, Apr 10, 2012 at 2:45 AM, Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:
> > On Fri, Apr 06, 2012 at 05:47:28PM +0000, Chen, Dennis (SRDC SW) wrote:
> >> On Fri, Apr 6, 2012 at 6:10 PM, Clemens Ladisch <clemens@ladisch.de> wrote:
> >> > Chen, Dennis (SRDC SW) wrote:
> >> >
> >> > "On the internet, nobody can hear you being subtle."
> >> >
> >> > If some other process wants to run on the same CPU, needs_resched() is set.
> >> > (This might happen to make the cursor blink, for keyboard input, or when
> >> > somebody starts a rogue process like ps.)
> >> >
> >>
> >> Hmm, I forget that in each timer interrupt, __rcu_pending() will be called, it will call
> >> set_need_resched() to set the TIF_NEED_RESCHED in some condition...
> >> The optimization of mutex work closely with rcu, so fantastic!
> >
> > I must confess that you all lost me on this one.
> >
> > There is a call to set_need_resched() in __rcu_pending(), which is
> > invoked when the current CPU has not yet responded to a non-preemptible
> > RCU grace period for some time. However, in the common case where the
> > CPUs all respond in reasonable time, __rcu_pending() will never call
> > set_need_resched().
> >
> > However, we really do not want to call set_need_resched() on every call
> > to __rcu_pending(). There is almost certainly a better solution to any
> > problem that might be solved by a per-jiffy call to set_need_resched().
> >
> > So, what are you really trying to do?
> >
> > Thanx, Paul
>
> Paul, I must confess that maybe you're right, I've realized the misunderstanding in the previous email.
> But I don't want to pretend that I have a full understanding for your " There is almost certainly a
> better solution to any problem that might be solved by a per-jiffy call to set_need_resched()", because
> this is related with your last question.
>
> I just want to measure the performance between semaphore and mutex, before that I looked at the mutex
> optimization code, and the focus is on the mutex_spin_on_owner() function, I don't know how long it will
> take before some components in the kernel call set_need_resched() to break the while loop. If it's on
> jiffies level, given the time of a process switch possibly in microsecond level, that means current
> process must spin for several jiffies before it got the mutex lock or go to sleep finally, I can't
> see the benefit here...

The loop spins only while a given task owns the lock. This means that
for the loop to spin for several jiffies, one of three things must happen:

1. The task holding the lock has been running continuously for
several jiffies. This would very likely be a bug. (Why are
you running CPU bound in the kernel for several jiffies,
whether or not you are holding a lock?)

2. The task spinning in mutex_spin_on_owner() happens to be being
preempted at exactly the same times as the owner is, and so
by poor luck happens to always see the owner running.

The probability of this is quite low, should (famous last words!)
can be safely ignored.

3. The task spinning in mutex_spin_on_owner() happens to be being
preempted at exactly the same times that the owner releases
the lock, and so again by poor luck happens to always see the
owner running.

The probability of this is quite low, should (famous last words!)
can be safely ignored.

Normally, the lock holder either blocks or releases the lock quickly,
so that mutex_spin_on_owner() exits its loop.

So, are you seeing a situation where mutex_spin_on_owner() really is
spinning for multiple jiffies?

Thanx, Paul



\
 
 \ /
  Last update: 2012-04-11 19:35    [W:0.077 / U:0.624 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site