Messages in this thread | | | Date | Sat, 27 Sep 2008 22:48:34 +0200 | From | Ingo Molnar <> | Subject | Re: How how latent should non-preemptive scheduling be? |
| |
* Sitsofe Wheeler <sitsofe@yahoo.com> wrote:
> Logs with the filtering on can be seen here (15Mbytes decompressed each): > http://sucs.org/~sits/test/eeepc-debug/20080923/latency_trace.gz > http://sucs.org/~sits/test/eeepc-debug/20080923/trace.txt.gz > > It looks like lots of acpi state is created and deleted...
yeah. The latency starts here:
cat-5901 0dNh. 1us : default_wake_function (__wake_up_common) cat-5901 0.Nh. 2us : kill_fasync (snd_pcm_period_elapsed) [...]
and ends here:
[...] cat-5901 0.N.. 270501us+: mutex_lock (acpi_ec_transaction) cat-5901 0d... 270507us : __cond_resched (_cond_resched)
270 _milliseconds_ later. That's excessive.
The main overhead is starting here:
cat-5901 0.N.. 167us : acpi_ds_result_push (acpi_ds_exec_end_op)
lots of ACPI code executed ...
does it get better if you have CONFIG_PREEMPT_VOLUNTARY=y enabled? That _should_ break up this section neatly. If it doesnt then please add a might_sleep() check to kernel/kernel/semaphore.c's down_timeout() function - that is called a number of times in this trace.
Ingo
| |