| Message ID | 201010271659.o9RGxrMc009847@farm-0002.internal.tilera.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Headers | show |
On Wed, 27 Oct 2010 12:54:27 -0400
Chris Metcalf <cmetcalf@tilera.com> wrote:
> The tile architecture uses this framework for our serial console,
That may be a mistake unless your console is genuinely only capable of
polled input.
Alan
On 10/27/2010 3:21 PM, Alan Cox wrote: > On Wed, 27 Oct 2010 12:54:27 -0400 Chris Metcalf <cmetcalf@tilera.com> wrote: >> The tile architecture uses this framework for our serial console, > That may be a mistake unless your console is genuinely only capable of > polled input. The console is in fact interrupt-driven within the hypervisor, and data is buffered there. However, the current hypervisor console API is only "write" and "read". We have a bugzilla to add console interrupts to the hypervisor API and use them from Linux, but we haven't done it yet.
On Wed, 2010-10-27 at 12:54 -0400, Chris Metcalf wrote: > The tile architecture uses this framework for our serial console, > and our users complain that the delay of up to two seconds feels like > the machine has gone non-responsive and is disturbing. By contrast, > a delay of up to half a second feels like just the normal sort of > delay caused by swapping, network lag, etc. and is not noticeable. > The overhead is obviously not much greater. It's 4 times greater. We picked 2 seconds because it gave a reasonable trade off between responsiveness and load. I'm not convinced that half a second is a better number. cheers
On 11/1/2010 8:35 PM, Michael Ellerman wrote: > On Wed, 2010-10-27 at 12:54 -0400, Chris Metcalf wrote: >> The tile architecture uses this framework for our serial console, >> and our users complain that the delay of up to two seconds feels like >> the machine has gone non-responsive and is disturbing. By contrast, >> a delay of up to half a second feels like just the normal sort of >> delay caused by swapping, network lag, etc. and is not noticeable. >> The overhead is obviously not much greater. > It's 4 times greater. > > We picked 2 seconds because it gave a reasonable trade off between > responsiveness and load. I'm not convinced that half a second is a > better number. Perhaps the tradeoff should be tunable, then? I think on our architecture we're willing to pay a higher cost on the core running this task, since we have many cores; we often have a core that mostly just runs miscellaneous Linux administrative tasks anyway, so adding a bit more overhead there is not significant for us. This issue has caused multiple reports of unresponsiveness from our users, so I'd be interested in finding a way to strike a balance. We could use a config option defaulting to 2 seconds (for example), or something more dynamic (probably unnecessary). Let me know your preference, if this sounds plausible, and I'll write up a proposed patch. Thanks.
diff --git a/drivers/char/hvc_console.c b/drivers/char/hvc_console.c index 3afd62e..1df5431 100644 --- a/drivers/char/hvc_console.c +++ b/drivers/char/hvc_console.c @@ -565,11 +565,11 @@ static int hvc_chars_in_buffer(struct tty_struct *tty) * and during console activity we will use a default MIN_TIMEOUT of 10. When * the console is idle, we increase the timeout value on each pass through * msleep until we reach the max. This may be noticeable as a brief (average - * one second) delay on the console before the console responds to input when + * 0.25 second) delay on the console before the console responds to input when * there has been no input for some time. */ #define MIN_TIMEOUT (10) -#define MAX_TIMEOUT (2000) +#define MAX_TIMEOUT (500) static u32 timeout = MIN_TIMEOUT; #define HVC_POLL_READ 0x00000001
The tile architecture uses this framework for our serial console, and our users complain that the delay of up to two seconds feels like the machine has gone non-responsive and is disturbing. By contrast, a delay of up to half a second feels like just the normal sort of delay caused by swapping, network lag, etc. and is not noticeable. The overhead is obviously not much greater. Signed-off-by: Chris Metcalf <cmetcalf@tilera.com> --- I'm happy to push this via the tile tree if the linuxppc-dev folks want to give me an acked-by, or you can take it into your tree. Thanks! drivers/char/hvc_console.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)