Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 04 Sep 2014 12:20:11 +0100
From:      Bruce Simpson <bms@fastmail.net>
To:        =?ISO-8859-1?Q?Jean-S=E9bastien=20P=E9dron?= <dumbbell@FreeBSD.org>, Alexey Dokuchaev <danfe@FreeBSD.org>, Ed Maste <emaste@freebsd.org>
Cc:        svn-src-stable@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, svn-src-stable-10@freebsd.org
Subject:   Re: svn commit: r271023 - stable/10/sys/dev/vt
Message-ID:  <1409829611.1620282.163554161.0056EA09@webmail.messagingengine.com>
In-Reply-To: <54082B57.6070007@FreeBSD.org>
References:  <201409031400.s83E0bK6049810@svn.freebsd.org> <20140903140757.GA7494@FreeBSD.org> <CAPyFy2B8F_mWOeTGXormEQ2amzQ00rFotmsNpXmgaKTy63DYzA@mail.gmail.com> <20140903145753.GA25935@FreeBSD.org> <54082B57.6070007@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 4 Sep 2014, at 10:05, Jean-S=E9bastien P=E9dron wrote:
> Unfortunately, reading from the video memory is very expensive. The new
> version of vt_vga never reads from the video memory. Instead, it uses
> the console history to know what those 8 pixels should look like and
> write one byte which doesn't need further processing.
...=20
> Those two problems combined explain the slownness of vt(4), especially
> with discrete GPU and virtual machines; i915 users were mostly spared.

It may be a good idea to monitor the performance of vt(4) under virtual
KVM systems (e.g. Supermicro IPMI, VMware VNC, Cisco UCS etc.) for the
following reasons:

1) users of FreeBSD are likely to rely on them for operations,
2) many of these systems already work along similar principles (i.e.
delta compression),
3) to be sure that cascaded updates don't cause additional display
latency.

--=20
BMS (sent via webmail)



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1409829611.1620282.163554161.0056EA09>