[PATCH] powerpc: Make rtas console _much_ faster

[PATCH] powerpc: Make rtas console _much_ faster

[Michael Ellerman]

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.

I'll test this on P5 LPAR, is there anyone else that uses hvc_console?
Thoughts?

Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---

 drivers/char/hvc_console.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: cell/drivers/char/hvc_console.c
===================================================================
--- cell.orig/drivers/char/hvc_console.c
+++ cell/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;

Re: [PATCH] powerpc: Make rtas console _much_ faster

[Olof Johansson]

On Tue, Apr 18, 2006 at 08:55:29PM +0200, Michael Ellerman wrote:

> I'll test this on P5 LPAR, is there anyone else that uses hvc_console?
> Thoughts?

I have an out-of-tree HVC backend here for a simple simulator console
(will never make it in-tree since it's never going to see other users). So
not that it really matters, but the patch is OK for that environment.

The only other case I can think of is if the backend really needs some
time to clear out data, if we end up spinning too much in the yield()
loop. POWER4 with HVC console is a possible candidate there, since all
partitions share a 19200bps line for consoles.

> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>

Assuming it's not an issue on POWER4 LPAR:

Acked-by: Olof Johansson <olof@lixom.net>

Re: [PATCH] powerpc: Make rtas console _much_ faster

[Ryan Arnold]

On Tue, 2006-04-18 at 20:55 +0200, Michael Ellerman wrote:

> 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.

I think I'm the guilty part and I removed that code because it was silly
to be pushing to the tty with a partially filled buffer when we could
pack it up full.  The original intention of HVC_POLL_QUICK was for
letting the TTY grok the data read from firmware.  I think I was just
worried about 'off by one' errors and did it to be safe.  I didn't count
on the write frequency side-effect

The hvc_console was originally quite speedy after I added khvcd (before
it was broken apart into back-end/front-end).  We should review it for
performance on all platforms again in the future.

> 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.

You might as well use HVC_POLL_QUICK to speed up the write.  I put that
construct in for quick reading, not quick writing but it is a dead at
the moment.  Maybe rename it HVC_WRITE_QUICK?

> I'll test this on P5 LPAR, is there anyone else that uses hvc_console?
> Thoughts?

btw, there are a lot of users of hvc_console, power4 (non-interrupt
driven), power5 (interrupt-driven), cbe simulator, and rtas console.

Is it possible to make the poll frequency platform dependent?

-- 
Ryan S. Arnold <rsa@us.ibm.com>
IBM Linux Technology Center
Linux on Power Toolchain

question on why hvc_console calls hvc_poll() in hvc_handle_interrupt().

[Ryan Arnold]

While on the topic of hvc_console; I think I saw a patch go through a
while ago that added hvc_poll() to hvc_handle_interrupt().  I can't say
I'm too pleased with that addition.  I did my best to keep locking
outside of the interrupt handler.

I wonder if that change was tested on a power5 lpar system with several
secondary VSerial Server adapters (hvc1-hvcn) being hammered with data.
I'm pretty paranoid about deadlock, hence the reason for keeping locking
out of the int. handler.
-- 
Ryan S. Arnold <rsa@us.ibm.com>
IBM Linux Technology Center
Linux on Power Toolchain

[PATCH] powerpc: Make rtas console _much_ faster

[Michael Ellerman]

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.

The khvcd thread will eventually wake up and try to push more characters, which
will usually work because by then the firmware's had time to make room. But
the khvcd thread only wakes up every 10 milliseconds, which isn't fast enough.

So change the khvcd thread logic so that if there's an incomplete write we
yield() and then immediately try writing again. Doing so makes POLL_QUICK and
POLL_WRITE synonymous, so remove POLL_QUICK.

With this patch our "benchmark" takes ~2.8 seconds.

Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---

 drivers/char/hvc_console.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Index: cell/drivers/char/hvc_console.c
===================================================================
--- cell.orig/drivers/char/hvc_console.c
+++ cell/drivers/char/hvc_console.c
@@ -553,7 +553,6 @@ static int hvc_chars_in_buffer(struct tt
 
 #define HVC_POLL_READ	0x00000001
 #define HVC_POLL_WRITE	0x00000002
-#define HVC_POLL_QUICK	0x00000004
 
 static int hvc_poll(struct hvc_struct *hp)
 {
@@ -568,6 +567,7 @@ static int hvc_poll(struct hvc_struct *h
 	/* Push pending writes */
 	if (hp->n_outbuf > 0)
 		hvc_push(hp);
+
 	/* Reschedule us if still some write pending */
 	if (hp->n_outbuf > 0)
 		poll_mask |= HVC_POLL_WRITE;
@@ -680,7 +680,7 @@ int khvcd(void *unused)
 			poll_mask |= HVC_POLL_READ;
 		if (hvc_kicked)
 			continue;
-		if (poll_mask & HVC_POLL_QUICK) {
+		if (poll_mask & HVC_POLL_WRITE) {
 			yield();
 			continue;
 		}

Re: question on why hvc_console calls hvc_poll() in hvc_handle_interrupt().

[Michael Ellerman]

[-- Attachment #1: Type: text/plain, Size: 867 bytes --]

On Thu, 2006-04-20 at 15:25 -0500, Ryan Arnold wrote:
> While on the topic of hvc_console; I think I saw a patch go through a
> while ago that added hvc_poll() to hvc_handle_interrupt().  I can't say
> I'm too pleased with that addition.  I did my best to keep locking
> outside of the interrupt handler.
> 
> I wonder if that change was tested on a power5 lpar system with several
> secondary VSerial Server adapters (hvc1-hvcn) being hammered with data.
> I'm pretty paranoid about deadlock, hence the reason for keeping locking
> out of the int. handler.

That was Milton's patch. No idea whether it's correct/tested.

cheers

-- 
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 --]