linux-kernel - Re: [patch 0/3] kvm tool: Serial emulation overhaul

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20111211103047.GA19299@elte.hu>
Date:	Sun, 11 Dec 2011 11:30:47 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Pekka Enberg <penberg@...nel.org>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>,
	Sasha Levin <levinsasha928@...il.com>
Subject: Re: [patch 0/3] kvm tool: Serial emulation overhaul

* Pekka Enberg <penberg@...nel.org> wrote:

> On Sat, 10 Dec 2011, Thomas Gleixner wrote:
>
> > There is a slight problem with them. I only tested them with 
> > the rt-guest kernels, but non rt kernels are slightly 
> > unhappy. Sorry for not thinking about that.
> >
> > Fix below.
> 
> Applied, thanks!
> 
> Ingo, how does serial console work for you with latest master? 
> It's likely that Thomas' patches fix top slowness for you.

It didnt get worse - but i can still easily tell apart a 'top' 
running under kvm than native. Try something like this:

 run top and type 's0.1<enter>' to change the refresh interval 
 to 100 msecs.

Run the same thing under kvm and on the native host. The two are 
visibly different: the kvm one refreshes with the cursor showing 
up mid-refresh a number of times.

In theory a kvm driven serial console should be extremely fast, 
much faster than a real serial console, basically as fast as a 
local console. Yet this still does not seem to be the case.

In fact even ssh-ing in to a box over Wifi and running the above 
top session is undistinguishable from top running in a local 
console. So IMO it cannot be virtualization overhead - there 
must still be some delay or serious lack of buffering somewhere.

Here's a way to measure the slowdown directly:

  time top -d 0.01 -n 10 -b

         native: 0.9 secs
  ssh over wifi: 1.4 secs
     kvm serial: 5.0 secs

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/