Some doubts on MUTEX

Some doubts on MUTEX

[subin gangadharan]

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?

Thanks in advance

Subin Gangadharan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110222/eaeaa211/attachment.html 

Some doubts on MUTEX

[Dave Hylands]

Hi Subin,

On Tue, Feb 22, 2011 at 4:00 PM, subin gangadharan
<subingangadharan@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.

Dave Hylands

Some doubts on MUTEX

[subin gangadharan]

On Tue, Feb 22, 2011 at 3:20 PM, Dave Hylands <dhylands@gmail.com> wrote:

> Hi Subin,
>
> On Tue, Feb 22, 2011 at 4:00 PM, subin gangadharan
> <subingangadharan@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"


> Dave Hyland
>




-- 
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/20110222/1b607fa6/attachment.html 

Some doubts on MUTEX

[Dave Hylands]

Hi Subin,

On Tue, Feb 22, 2011 at 8:58 PM, subin gangadharan
<subingangadharan@gmail.com> wrote:
>
>
> On Tue, Feb 22, 2011 at 3:20 PM, Dave Hylands <dhylands@gmail.com> wrote:
>>
>> Hi Subin,
>>
>> On Tue, Feb 22, 2011 at 4:00 PM, subin gangadharan
>> <subingangadharan@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

Some doubts on MUTEX

[subin gangadharan]

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

> Hi Subin,
>
> On Tue, Feb 22, 2011 at 8:58 PM, subin gangadharan
> <subingangadharan@gmail.com> wrote:
> >
> >
> > On Tue, Feb 22, 2011 at 3:20 PM, Dave Hylands <dhylands@gmail.com>
> wrote:
> >>
> >> Hi Subin,
> >>
> >> On Tue, Feb 22, 2011 at 4:00 PM, subin gangadharan
> >> <subingangadharan@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