WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] early_cpu_init() and identify_cpu()

To: Jan Beulich <jbeulich@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] early_cpu_init() and identify_cpu()
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Mon, 16 Jul 2007 07:25:09 +0100
Delivery-date: Sun, 15 Jul 2007 23:19:38 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <469B28F5.76E4.0078.0@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcfHcg6wTXkaHjNlEdy/8QAWy6hiGQ==
Thread-topic: [Xen-devel] early_cpu_init() and identify_cpu()
User-agent: Microsoft-Entourage/11.3.3.061214
On 16/7/07 07:14, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

> I've never seen a BIOS set the frame buffer to WC (or anything other than
> uncachable), presumably not the least because the address space may get
> laid out anew by the OS. And the performance loss in our case is quite
> significant (though I assume WC would at best help a little, I'm considering
> other approaches, too): Scrolling a 1280x1024x16 screen takes, on the test
> system I'm primarily trying this out on, on the order of a second. This is
> because we will want to not disturb what dom0 may have written to the
> screen, and hence we can't simply redraw. And I'm not certain I want to
> special case boot time here (although I may have no other option - delay
> in that order can easily lead to other failures [like CPUs not properly coming
> up]).
> 
> Of course, I could make the two stage vesafb initialization as it is right now
> a three stage one, doing just the MTRR request in the last. But I wanted to
> avoid making the code more spaghetti like than necessary just because of
> this little feature...

I'd rather have a later call (but not that late -- before secondary CPUs
come up is fine) than re-order start-of-day cpu detection code. At least in
a first patchset! The MTRR update will still happen before scrolling needs
to occur for the first time, and I don't see that the code will become
spaghetti because of it.

By the way, what makes you think that redrawing the whole screen (presumably
re-pasting text characters one-by-one) would be faster than scrolling?
Sounds slower to me, or is this because read-plus-write of UC memory sucks?

How much faster is scrolling of WC framebuffer on your test system?

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel