On Wed, Feb 23, 2011 at 2:04 AM, Dave Hylands [off-list ref] wrote:

Hi Subin,

On Tue, Feb 22, 2011 at 8:58 PM, subin gangadharan
[off-list ref] wrote:

quoted

On Tue, Feb 22, 2011 at 3:20 PM, Dave Hylands [off-list ref]

wrote:

quoted

quoted

Hi Subin,

On Tue, Feb 22, 2011 at 4:00 PM, subin gangadharan
[off-list ref] wrote:

quoted

Hi All,
I am trying to understand how to use mutex API's properly,so while

going

quoted

quoted

quoted

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.

quoted

quoted

quoted

 * We also put the fastpath first in the kernel image, to make sure

the

quoted

quoted

quoted

 * 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

quoted

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