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

Bill Davidsen
2007-03-20T14:43:53Z

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@tmr.com>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979