Re: [PATCH 1/3] RFC: Solved unnecessary schedule latency in the TTY layer (1/3)
From: Ivo Sieben <hidden>
Date: 2012-05-07 14:10:17
Also in:
linux-rt-users
Hi, 2012/5/3 Ivo Sieben [off-list ref]:
quoted hunk ↗ jump to hunk
--- a/drivers/tty/tty_buffer.c +++ b/drivers/tty/tty_buffer.c@@ -317,12 +317,7 @@ EXPORT_SYMBOL(tty_insert_flip_string_flags);void tty_schedule_flip(struct tty_struct *tty) { - unsigned long flags; - spin_lock_irqsave(&tty->buf.lock, flags); - if (tty->buf.tail != NULL) - tty->buf.tail->commit = tty->buf.tail->used; - spin_unlock_irqrestore(&tty->buf.lock, flags); - schedule_work(&tty->buf.work); + tty_flip_buffer_push(tty); } EXPORT_SYMBOL(tty_schedule_flip);
I have an additional question on the above change in the patch that I've send: I found that two functions in drivers/tty/tty_buffer.c implement almost the same functionality: - tty_schedule_flip - tty_flip_buffer_push Only difference was that tty_schedule_flip() always uses the work queue, while the tty_flip_buffer_push only uses the work queue in case of a non prempt_rt system and low_latency flag unset. But is my change correct? I see that most serial drivers use the tty_flip_buffer_push() function. But still a number of drivers use the tty_schedule_flip() function. I even found one driver that uses both (drivers/staging/serqt_usb2/serqt_usb2.c). Does my patch introduce bugs to these drivers? Or is the tty_schedule_flip() a legacy function, and would it be better to remove it completely? 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