Re: [PATCH 2/3] RFC: Solved unnecessary schedule latency in the TTY layer (2/3)

[Ivo Sieben <meltedpianoman@gmail.com>]

Hi,

2012/5/3 Greg KH <gregkh@linuxfoundation.org>:
>
> Why, what does this cause to have happen?  What's the difference here
> that causes any speedups or latency fixes?
>

This patch solves the following scenario:
- A low priority process starts to send data to serial port A
- In order to do this, the low priority process calls the
tty_ldisc_ref_wait() function to retrieve a reference to its line
discipline.
- In the tty_ldisc_ref_wait() function, the global ldisc spinlock is locked.
- While the spin lock is still locked, a context switch takes place
and a second process on high real-time priority starts reading data
from another serial port B (this is a possible scenario on a
PREEMPT_RT system where a "normal" spin lock behaves like a mutex and
no interrupts are actually disabled, although the "irqsave" postfix in
the spinlock function name suggests otherwise)
- The second project also calls the tty_ldisc_ref_wait() function, and
therefor gets blocked on the global ldisc spin lock.
- As a result priority inversion takes place, and the second process
is scheduled out, the first process is scheduled in on high priority.
After the first process has released the spin lock, the second process
is scheduled again.

The above scenario is not wrong, it works fine... but the scheduling &
mutex handling requires a lot of extra processing time what makes that
a normal read operation of about 50us sometimes can last up to 230us.
By using raw spin locks this situation is prevented. I think it is
legitimate to use raw spin locks because the critical sections in
ldisc are small.

Regards,
Ivo Sieben
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html