* Some doubts on MUTEX @ 2011-02-22 23:00 subin gangadharan 2011-02-22 23:20 ` Dave Hylands 0 siblings, 1 reply; 5+ messages in thread From: subin gangadharan @ 2011-02-22 23:00 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Some doubts on MUTEX 2011-02-22 23:00 Some doubts on MUTEX subin gangadharan @ 2011-02-22 23:20 ` Dave Hylands 2011-02-23 3:58 ` subin gangadharan 0 siblings, 1 reply; 5+ messages in thread From: Dave Hylands @ 2011-02-22 23:20 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Some doubts on MUTEX 2011-02-22 23:20 ` Dave Hylands @ 2011-02-23 3:58 ` subin gangadharan 2011-02-23 8:04 ` Dave Hylands 0 siblings, 1 reply; 5+ messages in thread From: subin gangadharan @ 2011-02-23 3:58 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Some doubts on MUTEX 2011-02-23 3:58 ` subin gangadharan @ 2011-02-23 8:04 ` Dave Hylands 2011-02-23 15:03 ` subin gangadharan 0 siblings, 1 reply; 5+ messages in thread From: Dave Hylands @ 2011-02-23 8:04 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Some doubts on MUTEX 2011-02-23 8:04 ` Dave Hylands @ 2011-02-23 15:03 ` subin gangadharan 0 siblings, 0 replies; 5+ messages in thread From: subin gangadharan @ 2011-02-23 15:03 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-02-23 15:03 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-02-22 23:00 Some doubts on MUTEX subin gangadharan 2011-02-22 23:20 ` Dave Hylands 2011-02-23 3:58 ` subin gangadharan 2011-02-23 8:04 ` Dave Hylands 2011-02-23 15:03 ` subin gangadharan
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).