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

[Ivo Sieben <meltedpianoman@xxxxxxxxx>]

Hi,

2012/5/3 Ivo Sieben <meltedpianoman@xxxxxxxxx>:
> --- 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html