Some doubts on MUTEX

[subin gangadharan]

On Wed, Feb 23, 2011 at 2:04 AM, Dave Hylands <dhylands at gmail.com> wrote:

> Hi Subin,
>
> On Tue, Feb 22, 2011 at 8:58 PM, subin gangadharan
> <subingangadharan at gmail.com> wrote:
> >
> >
> > On Tue, Feb 22, 2011 at 3:20 PM, Dave Hylands <dhylands at gmail.com>
> wrote:
> >>
> >> Hi Subin,
> >>
> >> On Tue, Feb 22, 2011 at 4:00 PM, subin gangadharan
> >> <subingangadharan at gmail.com> wrote:
> >> > Hi All,
> >> > I am trying to understand how to use mutex API's properly,so while
> going
> >> > through the documentation,
> >> > there is section mentioning fast path and slow path for mutexes.
> >> > For your reference I am pasting this here.(kernel/mutex.c)
> >> > /*
> >> >  * We split the mutex lock/unlock logic into separate fastpath and
> >> >  * slowpath functions, to reduce the register pressure on the
> fastpath.
> >> >  * We also put the fastpath first in the kernel image, to make sure
> the
> >> >  * branch is predicted by the CPU as default-untaken.
> >> >  */
> >> > static __used noinline void __sched
> >> > __mutex_lock_slowpath(atomic_t *lock_count);
> >> >
> >> > Can someone help me to understand what is the difference between
> >> > fastpath
> >> > lock and slowpath lock?
> >>
> >> The fastpath is taken when nobody else is holding the lock (so the
> >> caller acquires the mutex without blocking).
> >>
> >> The slowpath is taken when somebody else is holding the lock and the
> >> caller needs to block (i.e. sleep) until the mutex is released.
> >>
> > Thanks David.
> > Could you give a bit more idea on the "How this reduce the register
> pressure
> > on fast path"
>
> The code for the slowpath is considerably more complex than the code
> for the fastpath. So the fastpath will need much fewer registers.
> Since the compiler needs to generate save/restore operations for many
> touched registers, by having the slow path in a separate function, the
> extra save/restores are only done if they're needed.
>
> The fastpath does the minimal amount required, so fewer registers will
> be required and less saving/restoring needs to be done.
>
> Dave Hylands
>
Hi David,
Now I got it.Thanks again for your time and the clear explanation you gave
me.


-- 
With Regards
Subin Gangadharan

Everything should be made as simple as possible,but not simpler.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110223/28d52aad/attachment.html