From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: the cost of _raw_spin_lock in arm linux
Date: Fri, 23 May 2014 11:58:25 +0100 [thread overview]
Message-ID: <20140523105825.GU3693@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <OF33C6F1E2.8DD5197C-ON48257CE1.0037D051-48257CE1.0037D052@spreadtrum.com>
On Fri, May 23, 2014 at 06:09:38PM +0800, Xing.Wei at spreadtrum.com wrote:
> I'm a sw engineer from the mobile soc company named spreadtrum.
> And our soc based on arm smp cortex-A7 with 4 cores, all runs at fixed 600Mhz.
> We found a problem that the coreX which will be unplugged take about more than 40ms
> to excute the take_cpu_down function(migrate irqs, migrate tasks, etc), the result is all other online cores have to
> wait for the coreX finish that with irq disabled.
> So I use ftrace to analyze this problem.
One of the most basic points here is the Schrodinger's cat problem - that
you can't measure the system without affecting it. That is very true of
ftrace - it imposes significant overheads which can change the timing
quite considerably.
The second point is that if you have things like lockdep enabled or other
debugging options, the otherwise lightweight spinlocks become really quite
heavy.
So, if you're doing development, you should have things like lockdep and
other debugging options enabled to help find bugs in your code. Once
you've debugged the code and you're ready to start caring about
performance, you need to turn all those debugging options off (but don't
forget to turn them back on to check for newly introduced bugs afterwards.)
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
parent reply other threads:[~2014-05-23 10:58 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <OF33C6F1E2.8DD5197C-ON48257CE1.0037D051-48257CE1.0037D052@spreadtrum.com>]
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=20140523105825.GU3693@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=linux-arm-kernel@lists.infradead.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).