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

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 16/7/07 07:41, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

>> 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?
> 
> Yes, exactly that (really its presumably mostly the data dependency of the
> writes on the reads, which in a write-only scenario is so much smaller).
> 
>> How much faster is scrolling of WC framebuffer on your test system?
> 
> Haven't tested yet, as I haven't made the adjustments to make WC work so far
> (finding why it doesn't work was the last thing I did on Friday)... But as I
> said,
> I don't expect much gain from *just* the attribute change, as reads will
> continue
> to be done UC. As I said, I'm considering alternatives...

Yes, I'd be surprised if WC is that much of a win, since Linux certainly
doesn't appear to mess with MTRRs by default.

The best option would be to re-draw until dom0 starts to boot. After that
switch to scroll, but from that point on Xen doesn't write much to the
console anyway. Supporting both ways doesn't sound that hard, and there's
already a console_endboot() hook to trigger the switch in behaviour.

But if Linux re-draws the whole screen instead of scrolling, won't Xen's
output get overwritten anyway? That would limit 'vga=keep's usefulness,
except for crash dumps after which Linux dom0 will not print any more (I
suppose that is the main most useful case though). And if Linux *does*
scroll, how come *its* performance doesn't suck?

 -- Keir



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