From: Michael Ellerman <michael@ellerman.id.au>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Arnd Bergmann <arnd.bergmann@de.ibm.com>,
linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org,
Paul Mackerras <paulus@samba.org>,
cbe-oss-dev@ozlabs.org
Subject: Re: [PATCH 1/3] powerpc: Make rtas console _much_ faster
Date: Sat, 29 Apr 2006 11:56:57 +1000 [thread overview]
Message-ID: <1146275817.14733.2.camel@localhost.localdomain> (raw)
In-Reply-To: <200604290245.57507.arnd@arndb.de>
[-- Attachment #1: Type: text/plain, Size: 2562 bytes --]
I'll clean this one up a little before merging it as per Ryan's email of
a week or two ago. New patch today or tomorrow.
Even though this is 1/3 the rest of the series should be fine to merge,
right Arnd?
cheers
On Sat, 2006-04-29 at 02:45 +0200, Arnd Bergmann wrote:
> Currently the hvc_rtas driver is painfully slow to use. Our "benchmark" is
> ls -R /etc, which spits out about 27866 characters. The theoretical maximum
> speed would be about 2.2 seconds, the current code takes ~50 seconds.
>
> The core of the problem is that sometimes when the tty layer asks us to push
> characters the firmware isn't able to handle some or all of them, and so
> returns an error. The current code sees this and just returns to the tty code
> with the buffer half sent.
>
> There's the khvcd thread which will eventually wake up and try to push more
> characters, that will usually work because the firmware's had time to push
> the characters out. But the thread only wakes up every 10 milliseconds, which
> isn't fast enough.
>
> There's already code in the hvc_console driver to make the khvcd thread do
> a "quick" loop, where it just calls yield() instead of sleeping. The only code
> that triggered that behaviour was recently removed though, which I don't
> quite understand.
>
> Still, if we set HVC_POLL_QUICK whenever the push hvc_push() doesn't push all
> characters (ie. RTAS blocks), we can get good performance out of the hvc_rtas
> backend. With this patch the "benchmark" takes ~2.8 seconds.
>
> Cc: Ryan Arnold <rsa@us.ibm.com>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
>
> ---
>
> drivers/char/hvc_console.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: linus-2.6/drivers/char/hvc_console.c
> ===================================================================
> --- linus-2.6.orig/drivers/char/hvc_console.c
> +++ linus-2.6/drivers/char/hvc_console.c
> @@ -570,7 +570,7 @@ static int hvc_poll(struct hvc_struct *h
> hvc_push(hp);
> /* Reschedule us if still some write pending */
> if (hp->n_outbuf > 0)
> - poll_mask |= HVC_POLL_WRITE;
> + poll_mask |= HVC_POLL_WRITE | HVC_POLL_QUICK;
>
> /* No tty attached, just skip */
> tty = hp->tty;
>
> --
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <michael@ellerman.id.au>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Paul Mackerras <paulus@samba.org>,
cbe-oss-dev@ozlabs.org, linuxppc-dev@ozlabs.org,
linux-kernel@vger.kernel.org, Ryan Arnold <rsa@us.ibm.com>,
Arnd Bergmann <arnd.bergmann@de.ibm.com>
Subject: Re: [PATCH 1/3] powerpc: Make rtas console _much_ faster
Date: Sat, 29 Apr 2006 11:56:57 +1000 [thread overview]
Message-ID: <1146275817.14733.2.camel@localhost.localdomain> (raw)
In-Reply-To: <200604290245.57507.arnd@arndb.de>
[-- Attachment #1: Type: text/plain, Size: 2562 bytes --]
I'll clean this one up a little before merging it as per Ryan's email of
a week or two ago. New patch today or tomorrow.
Even though this is 1/3 the rest of the series should be fine to merge,
right Arnd?
cheers
On Sat, 2006-04-29 at 02:45 +0200, Arnd Bergmann wrote:
> Currently the hvc_rtas driver is painfully slow to use. Our "benchmark" is
> ls -R /etc, which spits out about 27866 characters. The theoretical maximum
> speed would be about 2.2 seconds, the current code takes ~50 seconds.
>
> The core of the problem is that sometimes when the tty layer asks us to push
> characters the firmware isn't able to handle some or all of them, and so
> returns an error. The current code sees this and just returns to the tty code
> with the buffer half sent.
>
> There's the khvcd thread which will eventually wake up and try to push more
> characters, that will usually work because the firmware's had time to push
> the characters out. But the thread only wakes up every 10 milliseconds, which
> isn't fast enough.
>
> There's already code in the hvc_console driver to make the khvcd thread do
> a "quick" loop, where it just calls yield() instead of sleeping. The only code
> that triggered that behaviour was recently removed though, which I don't
> quite understand.
>
> Still, if we set HVC_POLL_QUICK whenever the push hvc_push() doesn't push all
> characters (ie. RTAS blocks), we can get good performance out of the hvc_rtas
> backend. With this patch the "benchmark" takes ~2.8 seconds.
>
> Cc: Ryan Arnold <rsa@us.ibm.com>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
>
> ---
>
> drivers/char/hvc_console.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: linus-2.6/drivers/char/hvc_console.c
> ===================================================================
> --- linus-2.6.orig/drivers/char/hvc_console.c
> +++ linus-2.6/drivers/char/hvc_console.c
> @@ -570,7 +570,7 @@ static int hvc_poll(struct hvc_struct *h
> hvc_push(hp);
> /* Reschedule us if still some write pending */
> if (hp->n_outbuf > 0)
> - poll_mask |= HVC_POLL_WRITE;
> + poll_mask |= HVC_POLL_WRITE | HVC_POLL_QUICK;
>
> /* No tty attached, just skip */
> tty = hp->tty;
>
> --
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
next prev parent reply other threads:[~2006-04-29 1:56 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-29 0:40 [PATCH 0/3] cell: 2.6.17-rc3 bug fixes Arnd Bergmann
2006-04-29 0:40 ` Arnd Bergmann
2006-04-29 0:40 ` [PATCH 2/3] spufs: Disable local interrupts for SPE hash_page calls Arnd Bergmann
2006-04-29 0:40 ` Arnd Bergmann
2006-04-29 0:40 ` [PATCH 3/3] powerpc: update cell_defconfig Arnd Bergmann
2006-04-29 0:40 ` Arnd Bergmann
2006-04-29 0:45 ` [PATCH 1/3] powerpc: Make rtas console _much_ faster Arnd Bergmann
2006-04-29 0:45 ` Arnd Bergmann
2006-04-29 1:56 ` Michael Ellerman [this message]
2006-04-29 1:56 ` Michael Ellerman
2006-04-29 8:00 ` Arnd Bergmann
2006-04-29 8:00 ` Arnd Bergmann
2006-04-30 3:07 ` [PATCH] " Michael Ellerman
2006-04-30 3:07 ` Michael Ellerman
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=1146275817.14733.2.camel@localhost.localdomain \
--to=michael@ellerman.id.au \
--cc=arnd.bergmann@de.ibm.com \
--cc=arnd@arndb.de \
--cc=cbe-oss-dev@ozlabs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=paulus@samba.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.