From: Michael Ellerman <michael@ellerman.id.au>
To: Chris Metcalf <cmetcalf@tilera.com>
Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] drivers/char/hvc_console.c: reduce max idle timeout
Date: Tue, 02 Nov 2010 11:35:08 +1100 [thread overview]
Message-ID: <1288658108.16790.13.camel@concordia> (raw)
In-Reply-To: <201010271659.o9RGxrMc009847@farm-0002.internal.tilera.com>
[-- Attachment #1: Type: text/plain, Size: 648 bytes --]
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
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <michael@ellerman.id.au>
To: Chris Metcalf <cmetcalf@tilera.com>
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drivers/char/hvc_console.c: reduce max idle timeout
Date: Tue, 02 Nov 2010 11:35:08 +1100 [thread overview]
Message-ID: <1288658108.16790.13.camel@concordia> (raw)
In-Reply-To: <201010271659.o9RGxrMc009847@farm-0002.internal.tilera.com>
[-- Attachment #1: Type: text/plain, Size: 648 bytes --]
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
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2010-11-02 0:35 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-27 16:54 [PATCH] drivers/char/hvc_console.c: reduce max idle timeout Chris Metcalf
2010-10-27 19:21 ` Alan Cox
2010-10-27 19:21 ` Alan Cox
2010-10-27 19:46 ` Chris Metcalf
2010-10-27 19:46 ` Chris Metcalf
2010-11-02 0:35 ` Michael Ellerman [this message]
2010-11-02 0:35 ` Michael Ellerman
2010-11-02 2:21 ` Chris Metcalf
2010-11-02 2:21 ` Chris Metcalf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1288658108.16790.13.camel@concordia \
--to=michael@ellerman.id.au \
--cc=cmetcalf@tilera.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.