All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Sitsofe Wheeler <sitsofe@yahoo.com>
Cc: linux-kernel@vger.kernel.org,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Arjan van de Ven <arjan@infradead.org>,
	Steven Rostedt <rostedt@goodmis.org>
Subject: Re: How how latent should non-preemptive scheduling be?
Date: Mon, 29 Sep 2008 10:37:09 +0200	[thread overview]
Message-ID: <20080929083709.GD18663@elte.hu> (raw)
In-Reply-To: <48DFEF8A.3000502@yahoo.com>


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

> 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.

okay - then this definitely needs fixed.

>> _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?

hm, that's weird indeed. You could try to trace the full battery readout 
itself, via a script like this:

  cat /debug/tracing/trace > /dev/null        # drain trace
  cat /proc/acpi/whatever  
  cat /debug/tracing/trace > trace.txt

this way you should be seeing a full trace of the whole thing. (with the 
'ftrace' tracer plugin set in current_tracer)

then, assuming the trace.txt is complete, you can check where it 
reschedules and why. Search for 'schedule' calls. Compare the debug 
versus non-debug traces.

You can even turn on stack backtrace tracing feature, via:

  echo stacktrace > /debug/tracing/iter_ctrl

this adds extra trace entries that show the call path of every 
reschedule. [this attribute is default-disabled.]

	Ingo

  reply	other threads:[~2008-09-29  8:37 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <fa.ERZTl/6uH+mhNoef5fPJKTRjJag@ifi.uio.no>
     [not found] ` <fa.PtPFzP5kIJVCCov6YCewrh+o4z4@ifi.uio.no>
     [not found]   ` <fa.C6WSm5Rh2Nb+Qho7b0qDOZ9RPV8@ifi.uio.no>
     [not found]     ` <fa.ch6j4qXs/2sFpLkHz5fXrtjTR8c@ifi.uio.no>
     [not found]       ` <fa.Jx/Ygtm46CVRawlA6OnfYNn6cN0@ifi.uio.no>
2008-09-18  7:26         ` How how latent should non-preemptive scheduling be? Sitsofe Wheeler
     [not found]         ` <fa.iIHgL48F3T5VAqFw3mqaf9Pzrs4@ifi.uio.no>
     [not found]           ` <fa.Td8xkKZKMSMghlJmEYefTRVF2kc@ifi.uio.no>
2008-09-19 11:54             ` Sitsofe Wheeler
2008-09-19 14:20               ` Peter Zijlstra
2008-09-22 11:57               ` Ingo Molnar
2008-09-22 12:07                 ` Steven Rostedt
2008-09-23  6:33                 ` Sitsofe Wheeler
2008-09-23 11:53                   ` Ingo Molnar
2008-09-23 16:30                     ` Sitsofe Wheeler
2008-09-23 19:39                       ` Sitsofe Wheeler
2008-09-23 22:01                         ` Sitsofe Wheeler
2008-09-27 20:48                           ` Ingo Molnar
2008-09-28 20:56                             ` Sitsofe Wheeler
2008-09-29  8:37                               ` Ingo Molnar [this message]
2008-09-29 23:11                                 ` Sitsofe Wheeler
2008-09-30 11:22                                   ` Ingo Molnar
2008-09-30 13:18                                     ` Sitsofe Wheeler
2008-10-04 10:50                                       ` Reading EeePC900 battery info causes stalls when using SLUB (was Re: How how latent should non-preemptive scheduling be?) Sitsofe Wheeler
     [not found] <fa.vMKgvqjqmYnI2J40GHoTENeYm8U@ifi.uio.no>
     [not found] ` <fa.808p0ZtU9DCpeky4KfNS8Drdw9w@ifi.uio.no>
2008-09-17 21:48   ` How how latent should non-preemptive scheduling be? Sitsofe Wheeler
2008-09-17 21:54     ` Arjan van de Ven
2008-09-17 22:29       ` Sitsofe Wheeler
2008-09-18  2:42       ` Peter Zijlstra
2008-09-18 18:25         ` Sitsofe Wheeler
2008-09-19  8:44           ` Ingo Molnar
2008-09-17 21:18 Sitsofe Wheeler
2008-09-17 21:28 ` Sitsofe Wheeler
2008-09-17 21:34 ` Arjan van de Ven
2008-09-21 20:56 ` Matt Keenan
2008-09-22  6:50   ` Sitsofe Wheeler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080929083709.GD18663@elte.hu \
    --to=mingo@elte.hu \
    --cc=a.p.zijlstra@chello.nl \
    --cc=arjan@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=sitsofe@yahoo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.