[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <48DFEF8A.3000502@yahoo.com>
Date: Sun, 28 Sep 2008 21:56:42 +0100
From: Sitsofe Wheeler <sitsofe@...oo.com>
To: Ingo Molnar <mingo@...e.hu>
CC: linux-kernel@...r.kernel.org,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Arjan van de Ven <arjan@...radead.org>,
Steven Rostedt <rostedt@...dmis.org>
Subject: Re: How how latent should non-preemptive scheduling be?
Ingo Molnar wrote:
> does it get better if you have CONFIG_PREEMPT_VOLUNTARY=y enabled? That
CONFIG_PREEMPT_VOLUNTARY=y has always been enabled in these results.
> _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.
I added might_sleep() to the start of down_timeout() but it neither
printed anything to dmesg nor changed the latency issue...
Strangely stalling only seems to turn up in linux-tip kernels with very
little debugging options set within them. I have a linux-tip that has
lots of extra debugging options set and this problem doesn't show up...
I've also asked about this on the ACPI mailing list and had a huge
amount of help from finding a good point for a cond_resched -
http://marc.info/?l=linux-acpi&m=122236450105747&w=2 . Certain things
(like games) still stutter when the battery is read but it's enough to
play back sound in rhythmbox without stuttering.
Any ideas why the issue would go away with a debug kernel though?
--
Sitsofe | http://sucs.org/~sits/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists