hvc_console & interrupts: reworked patch

[Benjamin Herrenschmidt]

> My point earlier is that the hypervisor only sends a single interrupt
> concerning available data until all the data is removed from the HV.
> This int causes an hvc_kick() which wakes up the task running
> hvc_poll().
>
> If the hvc_poll() task is reading data and it predicts that our last HV
> read and tty flip may have throttled the TTY the hvc_poll() function
> calls yield() on the task and awaits a hvc_unthrottle call to hvc_kick()
> and wake the task.

Ugh ? We don't predict anyting, we just go out to the "quick" path to
yield, but that yield should not block, just leave time to other
processes and go straight back to poll. We only block if poll returns
a mask of 0.

> If we were wrong and the TTY wasn't throttled we won't receive an
> unthrottle() callback, nor another data interrupt (since we never pulled
> all the data), which means that the there won't be any further data read
> until the system returns control to this thread due to the yield() and
> its long sleeping nature.

yield is long sleeping ? I would have expected to be short, maybe we
should change it to a simple schedule() ...

Ben.


** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/