From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jonathan Austin Subject: Re: [PATCH v2 2/3] kvm tools: remove periodic tick in favour of a polling thread Date: Thu, 05 Sep 2013 17:39:49 +0100 Message-ID: <5228B3D5.1040808@arm.com> References: <1378301148-18823-1-git-send-email-jonathan.austin@arm.com> <1378301148-18823-3-git-send-email-jonathan.austin@arm.com> <52277097.8020008@arm.com> <5227758C.3000908@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Cc: Pekka Enberg , KVM General , Marc Zyngier , Will Deacon , Matt Evans , Asias He To: Sasha Levin Return-path: Received: from service87.mimecast.com ([91.220.42.44]:41644 "EHLO service87.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753815Ab3IEQkR convert rfc822-to-8bit (ORCPT ); Thu, 5 Sep 2013 12:40:17 -0400 In-Reply-To: <5227758C.3000908@oracle.com> Sender: kvm-owner@vger.kernel.org List-ID: Hi Sasha, On 04/09/13 19:01, Sasha Levin wrote: > On 09/04/2013 01:48 PM, Pekka Enberg wrote: >> On Wed, Sep 4, 2013 at 8:40 PM, Jonathan Austin wrote: >>> 'top' works on ARM with virtio console. I've just done some new testing >>> and with the serial console emulation and I see the same as you're reporting. >>> Previously with the 8250 emulation I'd booted to a prompt but didn't actually >>> test top... >>> >>> I'm looking in to fixing this now... Looks like I need to find the right place >>> from which to call serial8250_flush_tx now that it isn't getting called every tick. >>> >>> I've done the following and it works fixes 'top' with serial8250: >>> -------8<---------- >>> diff --git a/tools/kvm/hw/serial.c b/tools/kvm/hw/serial.c >>> index 931067f..a71e68d 100644 >>> --- a/tools/kvm/hw/serial.c >>> +++ b/tools/kvm/hw/serial.c >>> @@ -260,6 +260,7 @@ static bool serial8250_out(struct ioport *ioport, struct kvm *kvm, u16 port, >>> dev->lsr &= ~UART_LSR_TEMT; >>> if (dev->txcnt == FIFO_LEN / 2) >>> dev->lsr &= ~UART_LSR_THRE; >>> + serial8250_flush_tx(kvm, dev); >>> } else { >>> /* Should never happpen */ >>> dev->lsr &= ~(UART_LSR_TEMT | UART_LSR_THRE); >>> >>> ------------->8----------- >>> >>> I guess it's a shame that we'll be printing each character (admittedly the rate will always be >>> relatively low...) rather than flushing the buffer in a batch. Without a timer, though, I'm >>> not sure I see a better option - every N chars doesn't seem like a good one to me. >>> >>> If you think that looks about right then I'll fold that in to the patch series, probably also >>> removing the call to serial8250_flush_tx() in serial8250__receive. >> >> Yeah, looks good to me and makes top work again. > > We might want to make sure performance isn't hit with stuff that's intensive on the serial console. Indeed, the intention here is very much to reduce overhead... Do you have an idea already of what you'd like to test? I've written a little testcase that just prints an incrementing counter to the console in a tight loop for 5 seconds (I've tested both buffered and unbuffered output). The measure of 'performance' is how high we count in those 5 seconds. These are averages (mean) of 5 runs on x86. ----------------+unbuffered+-buffered-+ native | 36880 | 40354 | ----------------+----------+----------+ lkvm - original | 24302 | 25335 | ----------------+----------+----------+ lkvm - no-tick | 22895 | 28202 | ----------------+----------+----------+ I ran these all on the framebuffer console. I found that the numbers on gnome-terminal seemed to be affected by the activity level of other gui-ish things, and the numbers were different in gnome-terminal and xterm. If you want to see more testing then a suggestion of a way we can take host terminal performance out of the equation would make me more comfortable with the numbers. I do think that as comparisons to each other they're reasonable as they are, though. So at least in this reasonably artificial case it looks like a minor win for buffered output and a minor loss in the unbuffered case. Happy to try out other things if you're interested. Jonny > Thanks, > Sasha > >