Re: [linux-pm] [2/6] 2.6.21-rc2: known regressions

From: Bill Davidsen
Date: Tue Mar 20 2007 - 10:44:09 EST


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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/