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