[PATCH] EXA: Defragment offscreen memory.

Michel Dänzer michel at daenzer.net
Wed Feb 18 07:01:37 PST 2009


On Tue, 2009-02-17 at 15:26 -0500, Adam Jackson wrote:
> On Sat, 2009-02-14 at 19:03 +0100, Michel Dänzer wrote:
> > On Sat, 2009-02-14 at 09:01 -0800, Keith Packard wrote:
> > > On Sat, 2009-02-14 at 14:28 +0100, Michel Dänzer wrote:
> > > 
> > > > * The server is going idle.
> > > 
> > > The server calls the block handler every 20ms, not just when it is truly
> > > idle.
> > 
> > You learn something new every day...
> 
> To clarify:

Thank you Adam, I appreciate the clarification.


> > > If this operation is expensive, you may want to hack up the block
> > > and wakeup handlers to pend this until the server actually ended up
> > > sleeping.
> > 
> > How can I tell that? It shouldn't be too expensive usually and will only
> > actually run at most once per second anyway, but it would probably still
> > be better only to do it when the server is idle if that can be achieved
> > without too much effort.
> 
> Probably better to run the periodic defragger from a real timer, and arm
> it for 1s in the future from BlockHandler.  If the timer ever expires,
> you know you've been idle for a full second, so you can go ahead and do
> some idle work.  (Eventually, when you detect that you're as defragged
> as you're going to get, just destroy the timer.)  Technically this has a
> minor failing when a single request takes more than a second but if that
> ever happens you're not a happy camper anyway.

Do I understand your idea correctly: TimerSet in the BlockHandler,
TimerCancel in the WakeupHandler?

I think 1s is too long though, at least that wouldn't ever expire on my
systems. :) How about say 20ms? More/less? (Keep in mind that
ExaOffscreenDefragment() will only do its thing once per second at most
anyway, if it's called earlier again it returns immediately)


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer


More information about the xorg-devel mailing list