On Mon, 2007-03-19 at 16:33 -0400, Bill Davidsen wrote:
>
> What you say sounds good, assuming that the cost of a sleep is less than
> the cost of the busy wait. But this may be hardware, the waits may be
> very small and frequent, and if it's hitting a small hardware window
> like retrace, delays in response will cause the time period to be missed
> completely. This probably less critical with very smart cards, many of
> us don't run them.
> >
Actually, various strategies involving short busy waiting, or looking at
DMA address registers before sleeping were commonplace. But a
syscall/sleep/wakeup is/was pretty fast. If you have an operation
blitting the screen (e.g. scrolling), it takes a bit of time for the GPU
to execute the command. I see this right now on OLPC, where a wonderful
music application needs to scroll (most of) the screen left),
periodically, and we're losing samples sometimes at those operation.
Remember also, that being nice to everyone else by sleeping, there are
more cycles to go around, and the scheduler can nicely boost the X
server's priority as it will for "interactive" processes that are being
cooperative.
- Jim
--
Jim Gettys
One Laptop Per Child
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
