On Wed, Feb 23, 2011 at 2:04 AM, Dave Hylands <dhylands@xxxxxxxxx> wrote:
Hi Subin,
On Tue, Feb 22, 2011 at 8:58 PM, subin gangadharan
The code for the slowpath is considerably more complex than the code<subingangadharan@xxxxxxxxx> wrote:
>
>
> On Tue, Feb 22, 2011 at 3:20 PM, Dave Hylands <dhylands@xxxxxxxxx> wrote:
>>
>> Hi Subin,
>>
>> On Tue, Feb 22, 2011 at 4:00 PM, subin gangadharan
>> <subingangadharan@xxxxxxxxx> 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"
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.
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
