Hi Preeti, 2013/1/16 Preeti U Murthy <preeti@xxxxxxxxxxxxxxxxxx>: > Hi Ivo, > Can you explain how this problem could create a scheduler overhead? > I am a little confused, because as far as i know,scheduler does not come > in the picture of the wake up path right? select_task_rq() in > try_to_wake_up() is where the scheduler comes in,and this is after the > task wakes up. > Everytime the line discipline is dereferenced, the wakeup function is called. The wakeup() function contains a critical section protected by spinlocks. On a PREEMPT_RT system, a "normal" spinlock behaves just like a mutex: scheduling is not disabled and it is still possible that a new process on a higher RT priority is scheduled in. When a new - higher priority - process is scheduled in just when the put_ldisc() is in the critical section of the wakeup function, the higher priority process (that uses the same TTY instance) will finally also dereference the line discipline and try to wakeup the same waitqueue. This causes the high priority process to block on the same spinlock. Priority inheritance will solve this blocked situation by a context switch to the lower priority process, run until that process leaves the critical section, and a context switch back to the higher priority process. This is unnecessary since the waitqueue was empty after all (during normal operation the waitqueue is empty most of the time). This unnecessary context switch from/to the high priority process is what a mean with "scheduler overhead" (maybe not a good name for it, sorry for the confusion). Does this makes sense to you? Regards, ivo Sieben -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
