> instead of using a work queue in the background. Therefor only in case a > workqueue is actually used for copying data to the line discipline > we'll have to check & wait for the workqueue to finish. > > This prevents unnecessary spin lock/unlock on the workqueue spin lock that can > cause additional scheduling overhead on a PREEMPT_RT system. On a 240 MHz > AT91SAM9261 processor setup this fixes about 100us of scheduling overhead on the > TTY read call. This seems incredibly convoluted and complicated as well as asking for races and weirdness with the divisibility between the schedule_work and the atomic operation. If the only cases are: tty->low_latency = 0 call flush_work tty->low_latency = 1 don't call tty->low_latency changes call flush_work then surely the right fix is if (tty->low_latency == 0) flush_work(&tty->buf.work); and making the couple of spots we set/unset low latency on a running port somewhat smarter ? That avoids an expensive atomic operation as well (and atomic ops are very expensive on some platforms). Alan -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
