Some doubts on MUTEX

[Dave Hylands]

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