From: Simon Falsig <simon@newtec.dk>
To: Carsten Emde <C.Emde@osadl.org>, frank.rowand@am.sony.com
Cc: linux-rt-users@vger.kernel.org
Subject: RE: Real-time kernel thread performance and optimization
Date: Tue, 11 Dec 2012 15:43:39 +0100 [thread overview]
Message-ID: <d63382c92165debf7dfcb7c5a6097ee6@mail.gmail.com> (raw)
In-Reply-To: <50BCB40E.9050304@osadl.org>
> -----Original Message-----
> From: Carsten Emde [mailto:C.Emde@osadl.org]
> Sent: 3. december 2012 15:16
> To: frank.rowand@am.sony.com
> Cc: Simon Falsig; linux-rt-users@vger.kernel.org
> Subject: Re: Real-time kernel thread performance and optimization
>
> On 11/30/2012 11:31 PM, Frank Rowand wrote:
> > On 11/30/12 07:46, Simon Falsig wrote:
> >> [..]
> >> Bonus-question:
> >> - Additionally, I've tried running cyclictest alongside with all
> >> the above, and it actually performs rather well, without any
> >> substantial spikes. A strange thing is though, that the results are
> >> actually better with load than without? (running with -t1 -p 80 -n -i
10000 -l
> 10000)
> >> - Loaded: Min: 16, Avg: 41, Max: 177
> >> - No load: Min: 16, Avg: 97, Max: 263
> >
> > If the system is less loaded, then the idle thread might be able to
> > enter deeper levels of sleep. Deeper levels of sleep have larger
> > latencies to exit. You would have to look at your processor specific
> > values for exiting sleep states to see if this is sufficient to
> > explain the difference.
> If running a half-decent version of cyclictest, sleep states are
generally
> disabled while cyclictest is running. Please watch the line
> # /dev/cpu_dma_latency set to 0us
> which essentially documents this mechanism. Yes, the name of the
variable
> "cpu_dma_latency" is not obvious and cyclictest could do a better job by
> writing
> Wrote 0 to /dev/cpu_dma_latency and keeping the path open to prevent
> all cores from entering any sleep state but this is another story.
>
> A patch that was merged to 3.7 allows to individually enable or disable
sleep
> states of the ladder governor
>
(http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=6
2d
> 6ae880e3e76098d5e345decd2dce443975889).
> It smoothly applies to 3.6-RT as well. This allows to fine-tune the
sleep states
> by state and core, while the /dev/cpu_dma_latency mechanism acts on all
> states and cores, e.g. to disable sleep state 2 and all deeper states of
the
> ladder governor on core #0, use:
> echo 1 >/sys/devices/system/cpu/cpu0/cpuidle/state2/disable
>
> BTW: To analyze how much time a core spent in a specific sleep state,
simply
> look repeatedly at the "time" variable of a core's sleep state, e.g. for
core #0:
> # for i in /sys/devices/system/cpu/cpu0/cpuidle/state[0-4]
> > do
> > echo -e "`cat $i/name`:\t`cat $i/time`"
> > done
> POLL: 1342984105
> C1-IVB: 737109
> C3-IVB: 3852451
> C6-IVB: 1702683112
> C7-IVB: 4366946606
> While cyclictest is running with /dev/cpu_dma_latency set to 0, only the
POLL
> state times are increasing.
>
> -Carsten.
Thanks for the reply! As I wrote in my reply to Frank, I'm not completely
sure if P states are correctly implemented in our system. We're using a
custom BIOS for our custom board, and while P states do show up and are
modifiable (I've currently installed the userspace-governor, and am
manually setting the clock-frequency to the lowest possible at startup),
our board guy is not sure that changing it actually has any effect on the
processor. Yay...:/
So until I get a go-ahead on this, I'll wait with a further investigation.
Best regards,
Simon
next prev parent reply other threads:[~2012-12-11 14:43 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-30 15:46 Real-time kernel thread performance and optimization Simon Falsig
2012-11-30 22:31 ` Frank Rowand
2012-12-03 12:39 ` Simon Falsig
2012-12-03 14:15 ` Carsten Emde
2012-12-11 14:43 ` Simon Falsig [this message]
2012-12-19 8:10 ` Carsten Emde
2012-12-20 8:09 ` Simon Falsig
2012-12-19 14:59 ` John Kacur
2012-12-19 15:20 ` Carsten Emde
2012-12-11 14:30 ` Simon Falsig
2012-12-17 22:18 ` Frank Rowand
2012-12-20 0:11 ` Darren Hart
2012-12-20 8:21 ` Simon Falsig
2013-01-02 17:21 ` Darren Hart
2012-12-12 15:39 ` Simon Falsig
-- strict thread matches above, loose matches on Subject: below --
2013-07-11 6:32 Simon Falsig
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=d63382c92165debf7dfcb7c5a6097ee6@mail.gmail.com \
--to=simon@newtec.dk \
--cc=C.Emde@osadl.org \
--cc=frank.rowand@am.sony.com \
--cc=linux-rt-users@vger.kernel.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).