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>