Re: [PATCH][RFC] Adding information of counts processes acquired how many spinlocks to schedstat

[Andi Kleen]

On Wed, Jul 01, 2009 at 05:42:26PM +0900, Hitoshi Mitake wrote:
> From: Andi Kleen <andi@xxxxxxxxxxxxxx>
> Subject: Re: [PATCH][RFC] Adding information of counts processes acquired how many spinlocks to schedstat
> Date: Wed, 01 Jul 2009 09:38:04 +0200
> 
> > Hitoshi Mitake <mitake@xxxxxxxxxxxxxxxxxxxxx> writes:
> > 
> > > Hi,
> > >
> > > I wrote a test patch which add information of counts processes acquired how many spinlocks to schedstat.
> > > After applied this patch, /proc/<PID>/sched will change like this,
> > 
> > The problem is that spinlocks are very common and schedstats is enabled commonly
> > in production kernels. You would need to demonstrate that such a change doesn't
> > have significant performance impact. For me it looks like it has.
> 
> I agree with your opinion about performance impact.
> I thought this will make no problem,
> because schedstat is categorized as "Kernel hacking" section.
> But according to you, many production kernels enable it

Yes it's used by some performance management tools.

It might be still appropiate with a separate CONFIG option,
assuming the metric is actually useful (which is somewhat
questionable)

BTW I did spinlock counter statistics in the past with systemtap
(they're quite easy to do with it without any code changes), but I didn't find
them very useful to be honest.

> > Also I'm not sure exactly what good such a metric is. Do you have 
> > a concrete use case?
> > 
> 
> I want to know about behavior of Apache.

Spinlocks are mainly interesting when they use up CPU time.
This typically happens when they bounce cache lines or are
contended. On the other hand on modern CPUs "local only"
spinlocks that are not contended are quite cheap and 
not very interesting to optimize. For useful optimization
you need to distingush all these cases, and your 
simple counter doesn't help with that.

So I would suggest you just take a look at any of the 
standard kernel profilers (oprofile etc.) or at lockstat

> And spinlocks may cause terrible performance problem when Linux is running on VM.

Assuming a modern CPU the "uncontended lock spinlock" case shouldn't
be particularly expensive in VMs either.

> 
> > The normal way to check for lock contention or lock bouncingis to
> > simply profile cycles or time and see if there is a lot of CPU time in
> > locks.
> 
> According to Ingo's advice, I'll try to add lock counter to perfcounter.

Well that would have the same problem if that perfcounter is enabled.

-Andi

-- 
ak@xxxxxxxxxxxxxxx -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/