Jim Gettys wrote:
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.
None of that conflicts with what I said, but what works on an LCD may
not be appropriate for a CRT. With even moderate 1024x768@70 timing the
horizontal retrace happens ~50k/sec, and that's not an appropriate
syscall rate. I'm just pointing out that some things a video interface
does with simple hardware involve lots of very small windows. Don't read
that as "don't do it," just "be careful HOW you do it."
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.
I'm going to cautiously guess that the problem might be not "how much"
but "how soon." That is, latency might be more important than giving the
server a lot of CPU.
--
bill davidsen <davidsen@xxxxxxx>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
