[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC] Hacky MTRR support

From: Seth Goldberg
Subject: Re: [RFC] Hacky MTRR support
Date: Mon, 28 Jun 2010 10:32:41 -0700 (PDT)
User-agent: Alpine 2.00 (GSO 1167 2008-08-23)

Quoting Colin D Bennett, who wrote the following on Mon, 28 Jun 2010:

On Fri, 25 Jun 2010 09:58:34 +0100
Colin Watson <address@hidden> wrote:

I recently posted ("Subject: [PATCH] Optimise memset on i386" -
sorry, I don't seem to have a route to at the moment so
I can't post an archive link) about optimising GRUB's video
initialisation, and hinted that it might be possible to do better by
implementing MTRRs as well in order to allow the system to combine
writes to video memory rather than taking a cache stall for every
single write.  I can report that, at least on the hardware I was
using, it does make a significant difference: filling the screen with
solid colour now takes 10 milliseconds rather than 160!  This ended
up shaving about a second off the boot time of the project I'm
working on.

In addition to the improved startup speed, I see the potential for a
huge increase in graphical menu responsiveness if caching is enabled.
Would framebuffer draw and image blitting performance be improved by
using write-combining with MTRRs?

Yes, I think it would. I was thinking about this over the weekend and I think if we examine the PCI BARs and ensure that the memory we're adding to the variable-length MTRRs is marked prefetchable, that should exclude those cards that have registers mapped in that area (besides, I seriously doubt there would be registers in the framebuffer section of memory -- that would just be counterproductive for any graphics adapter), and should be the safety check vladimir's asking for as well.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]