Re: O(1) scheduler & interactivity improvements

From: Timothy Miller <miller@techsource.com>
To: Helge Hafting <helgehaf@aitel.hist.no>
Cc: John Bradford <john@grabjohn.com>,
	felipe_alfaro@linuxmail.org, linux-kernel@vger.kernel.org
Subject: Re: O(1) scheduler & interactivity improvements
Date: Wed, 25 Jun 2003 19:16:51 -0400	[thread overview]
Message-ID: <3EFA2D63.1010500@techsource.com> (raw)
In-Reply-To: 20030625214248.GB2753@hh.idb.hist.no

Helge Hafting wrote:
> On Tue, Jun 24, 2003 at 06:41:45PM -0400, Timothy Miller wrote:
> 
>>>
>>>That could be an interesting hack to a window manager - 
>>>don't start the move in opaque mode when the load is high.
>>
>>This isn't really an issue if the graphics engine is doing the work and 
>>the X server doesn't busy-wait on the bitblt to finish (ie. does DMA or 
>>calls ioctl to sleep until command-fifo-has-free-space interrupt).
> 
> 
> The problem isn't window movement, but all the stuff you uncover
> forcing repainting all over the place.

Quite true.  But once again, a well-written DDX will attempt to minimize 
any busy-waiting it does.  I can't remember if I'm thinking of the 
Matrox or Radeon drivers in XFree86, but they have code to do DMA, so 
all they do is fill up a buffer and go to sleep waiting on an ioctl. 
(I'm making an inference here, but isn't this what the DRM drivers are 
all about?)  The only time this doesn't work is when the drawing engine 
doesn't support the particular operation being done (or the DDX doesn't 
support it), and it's counter-productive to try to have mi reduce it to 
spans, or the drawing engine doesn't support DMA or interrupts.