From: Andi Kleen <andi@firstfloor.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp>,
andi@firstfloor.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH][RFC] Adding information of counts processes acquired how many spinlocks to schedstat
Date: Wed, 1 Jul 2009 14:40:55 +0200 [thread overview]
Message-ID: <20090701124055.GQ6760@one.firstfloor.org> (raw)
In-Reply-To: <20090701090749.GA13535@elte.hu>
> His arguments are bogus: both lockstat and perfcounters are optional
The patch was for schedstat, not lockstat.
> (and default off), and the sw counter can be made near zero cost
My understanding was that perfcounters was supposed to
be enabled on production kernels?
If not it would be fairly useless to most people who
don't recompile their kernels.
> even if both perfcounters and lockstat is enabled. Also, sw counters
> are generally per CPU, etc. so not a performance issue.
Uncontended spinlock is still a hotpath and adding code
to it will add overhead.
Without cache line bouncing it might not be fatal, but
making very fundamental micro operations like that slower
in production kernels doesn't seem like a good idea to me.
It would be especially sad since now in the x86 world we're
getting CPUs with fast LOCK prefix widely deplouyed and wasting
these improvements in Linux specific overhead again wouldn't
seem like the right direction to me.
Especially if it's quite dubious if the information gotten
through this counter is actually useful (or in the few cases
you really need it you can easily get with one of the
dynamic probing solutions)
One potential useful alternative metric I could imagine might
be useful be possible number of spins. I wouldn't have a problem with
that because spinning is already a slower path in the common
case. It might still cost a bit of SMT, but probably not fatal.
Still I suspect you can relatively easily get equivalent information
with a normal cycle profiler.
Benchmark numbers would be still a good idea of course.
> Andi is often trolling perfcounters related (and other) threads,
It's an interesting insight into your way of thinking that you now
consistently started to describe code review as trolling.
FYI I generally don't enjoy doing code review but do it anyways because I
think it's important to do to keep code quality up. Even if it doesn't
seem to be appreciated by people like you.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
next prev parent reply other threads:[~2009-07-01 12:41 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-01 6:21 [PATCH][RFC] Adding information of counts processes acquired how many spinlocks to schedstat Hitoshi Mitake
2009-07-01 7:31 ` Ingo Molnar
2009-07-01 8:21 ` Hitoshi Mitake
2009-07-01 13:45 ` Frederic Weisbecker
2009-07-01 13:50 ` Ingo Molnar
2009-07-01 14:17 ` mitake
2009-07-01 7:38 ` Andi Kleen
2009-07-01 8:42 ` Hitoshi Mitake
2009-07-01 9:07 ` Ingo Molnar
2009-07-01 9:42 ` Hitoshi Mitake
2009-07-01 11:06 ` Ingo Molnar
2009-07-01 12:53 ` Hitoshi Mitake
2009-07-01 15:44 ` Frederic Weisbecker
2009-07-06 5:20 ` mitake
2009-07-06 8:51 ` Peter Zijlstra
2009-07-06 11:54 ` Andi Kleen
2009-07-10 12:45 ` mitake
2009-07-10 12:52 ` Peter Zijlstra
2009-07-10 13:43 ` Ingo Molnar
2009-07-10 13:46 ` Frederic Weisbecker
2009-07-10 13:50 ` Ingo Molnar
2009-07-10 13:56 ` Peter Zijlstra
2009-07-12 7:23 ` Hitoshi Mitake
2009-07-12 13:24 ` Peter Zijlstra
2009-07-13 6:06 ` Hitoshi Mitake
2009-07-13 8:51 ` Ingo Molnar
2009-07-14 0:48 ` Hitoshi Mitake
2009-07-18 13:25 ` Ingo Molnar
2009-07-01 12:40 ` Andi Kleen [this message]
2009-07-01 13:50 ` [PATCH][RFC] Adding information of counts processes acquired how many spinlocks to schedstat II Andi Kleen
2009-07-01 9:48 ` [PATCH][RFC] Adding information of counts processes acquired how many spinlocks to schedstat Andi Kleen
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=20090701124055.GQ6760@one.firstfloor.org \
--to=andi@firstfloor.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mitake@dcl.info.waseda.ac.jp \
/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