Vishwas Manral wrote: >>Is there a performance related issue when using >> spinlocks(spinlock_t) instead of semaphores? Yes. On SMP systems, a spinlock will literally spin the CPU in place waiting for the resource to become available. A spinlock will not result in a context switch by the waiting thread. If the duration of the lock is small, then the amount of wasted CPU cycles is small, and spinlocks are better. Also, spinlocks are lower overhead to implement, so in the non-contended case they are more efficient. Thus spinlocks are better for quick, infrequently contended exclusion regions. Semaphores can sleep, which will result in a context switch. The overhead of a switch is high. Semaphores are better for long-held regions (things like holding a device structure while waiting on I/O, which might be arbitrarily long.) Basically the length of the lock hold has to outweigh the high cost of context switching and rescheduling. Also, If a region has multiple contenders, this also raises the variability and possible duration of the lock. Therefore, semaphores are better for long exclusion regions with potentially multiple contenders. -- Tim ============================= Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Electronics ============================= -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
