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

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

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