Re: Reading EeePC900 battery info causes stalls

[Ingo Molnar <mingo@elte.hu>]

* Sitsofe Wheeler <sitsofe@yahoo.com> wrote:

> Dagnabit I keep confusing people. This was actually intentional 
> because I wanted to know whether the latency I was seeing should have 
> been present in a non-preempt (but voluntary) kernel. You can see the 
> subject at that start of this thread: http://tinyurl.com/4akxa5 (How 
> how latent should non-preemptive scheduling be?). I'm not running a 
> sound studio where I need the lowest possible latency at all costs. 
> Further my current understanding is that the desktop distros don't 
> tend to ship "regular desktop kernels" with preemption (I know Ubuntu 
> 8.04 and Fedora 9 didn't).
>
> Basically I have the following queries: Do you have to have preemption 
> on if you are listening to music (without noticeable skips) and 
> playing the odd game (without noticeable pauses) on a desktop? What's 
> the allowed highest latency going to be over a few minutes in such 
> kernels?  Is it simply the case that if it's a non-preemptive kernel 
> latency no longer matters?

milliseconds of stalls is definitely excessive under a non-preempt 
kernel - and you have up to 500 msecs of stalls, right?

The simplest way you can fix such latencies is to look at the function 
trace, figure out which loop in the kernel takes so long to execute, and 
add a cond_resched() call to it. [there are other situations where a 
more complicated fix is needed, but this seems like a simpler scenario.]

	Ingo