From: Tim Sander <tim@krieglstein.org>
To: Stanislav Meduna <stano@meduna.org>
Cc: "linux-rt-users@vger.kernel.org" <linux-rt-users@vger.kernel.org>
Subject: Re: i.MX28 milliseconds latencies, interrupts disabled in arch_cpu_idle?
Date: Fri, 18 Apr 2014 18:09 +0200 [thread overview]
Message-ID: <9645151.cbKImklAq0@hydra> (raw)
In-Reply-To: <53503BD8.8000506@meduna.org>
Hi Stanislav
> Linux nxt 3.12.15-rt25+ #83 PREEMPT RT Thu Apr 17 20:54:00 CEST 2014
> armv5tejl GNU/Linux
>
>
> # tracer: irqsoff
> #
> # irqsoff latency trace v1.1.5 on 3.12.15-rt25+
> # --------------------------------------------------------------------
> # latency: 2224 us, #6/6, CPU#0 | (M:preempt VP:0, KP:0, SP:0 HP:0)
> # -----------------
> # | task: swapper-0 (uid:0 nice:0 policy:0 rt_prio:0)
> # -----------------
> # => started at: rcu_idle_enter
> # => ended at: arch_cpu_idle
> #
> #
> # _--------=> CPU#
> # / _-------=> irqs-off
> # | / _------=> need-resched
> # || / _-----=> need-resched_lazy
> # ||| / _----=> hardirq/softirq
> # |||| / _---=> preempt-depth
> # ||||| / _--=> preempt-lazy-depth
> # |||||| / _-=> migrate-disable
> # ||||||| / delay
> # cmd pid |||||||| time | caller
> # \ / |||||||| \ | /
> <idle>-0 0d...1.. 2us+: rcu_idle_enter
> <idle>-0 0d...2.. 11us+: T.796 <-rcu_idle_enter
> <idle>-0 0d...2.. 17us!: arch_cpu_idle <-cpu_startup_entry
> <idle>-0 0d...1.. 2219us+: arch_cpu_idle
> <idle>-0 0d...1.. 2234us+: trace_hardirqs_on <-arch_cpu_idle
> <idle>-0 0d...1.. 2303us : <stack trace>
> => arch_cpu_idle
> => cpu_startup_entry
> => start_kernel
>
> Why are interrupts disabled here (and are they really disabled)?
>
> $ egrep "IDLE|SMP|HZ" .config
> CONFIG_BROKEN_ON_SMP=y
> CONFIG_HZ_PERIODIC=y
> # CONFIG_NO_HZ_IDLE is not set
> # CONFIG_NO_HZ is not set
> CONFIG_GENERIC_SMP_IDLE_THREAD=y
> CONFIG_GENERIC_IDLE_POLL_SETUP=y
> CONFIG_HZ_FIXED=0
> # CONFIG_HZ_100 is not set
> # CONFIG_HZ_200 is not set
> CONFIG_HZ_250=y
> # CONFIG_HZ_300 is not set
> # CONFIG_HZ_500 is not set
> # CONFIG_HZ_1000 is not set
> CONFIG_HZ=250
> # CONFIG_CPU_IDLE is not set
> # CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set
>
> Configuring
> CONFIG_CPU_IDLE=y
> CONFIG_CPU_IDLE_GOV_LADDER=y
> does not help
>
> Maybe it is just some tracing infrastructure interference - the effect
> of enabling the tracing is huge on this platform for some reason.
> Just enabling the irqsoff tracing makes the machine unsuitable
> for any serious load.
Are you sure that this is not the cpu idle latency? I patched out the idle
mechanism on i.mx35 since waking up took much to long for RT usage.
The CPU is running a little hotter then, but after all the thermal envelop
always has to to cope with maximum load, so i guess this should do no harm
besides more energy churn.
Best regards
Tim
next prev parent reply other threads:[~2014-04-18 16:18 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-17 20:38 i.MX28 milliseconds latencies, interrupts disabled in arch_cpu_idle? Stanislav Meduna
2014-04-18 16:09 ` Tim Sander [this message]
2014-04-18 18:12 ` Stanislav Meduna
2014-04-18 22:21 ` Stanislav Meduna
2014-04-19 21:24 ` Tim Sander
2014-04-21 9:00 ` Stanislav Meduna
2014-04-19 10:36 ` Gilles Chanteperdrix
2014-04-21 9:11 ` Stanislav Meduna
2014-04-21 10:09 ` Gilles Chanteperdrix
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=9645151.cbKImklAq0@hydra \
--to=tim@krieglstein.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=stano@meduna.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).