From: Chris Metcalf <cmetcalf@tilera.com>
To: <michael@ellerman.id.au>
Cc: <linux-kernel@vger.kernel.org>, <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH] drivers/char/hvc_console.c: reduce max idle timeout
Date: Mon, 1 Nov 2010 22:21:15 -0400 [thread overview]
Message-ID: <4CCF759A.2010206@tilera.com> (raw)
In-Reply-To: <1288658108.16790.13.camel@concordia>
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.
--
Chris Metcalf, Tilera Corp.
http://www.tilera.com
WARNING: multiple messages have this Message-ID (diff)
From: Chris Metcalf <cmetcalf@tilera.com>
To: <michael@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drivers/char/hvc_console.c: reduce max idle timeout
Date: Mon, 1 Nov 2010 22:21:15 -0400 [thread overview]
Message-ID: <4CCF759A.2010206@tilera.com> (raw)
In-Reply-To: <1288658108.16790.13.camel@concordia>
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.
--
Chris Metcalf, Tilera Corp.
http://www.tilera.com
next prev parent reply other threads:[~2010-11-02 2:21 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
2010-11-02 0:35 ` Michael Ellerman
2010-11-02 2:21 ` Chris Metcalf [this message]
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=4CCF759A.2010206@tilera.com \
--to=cmetcalf@tilera.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=michael@ellerman.id.au \
/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.