From: Andi Kleen <andi@firstfloor.org>
To: Dave Kleikamp <dkleikamp@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Chris Mason <chris.mason@oracle.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Tim Chen <tim.c.chen@linux.intel.com>,
linux-kernel@vger.kernel.org, lenb@kernel.org,
paulmck@us.ibm.com
Subject: Re: idle issues running sembench on 128 cpus
Date: Wed, 04 May 2011 15:07:27 -0700 [thread overview]
Message-ID: <m2pqnyyva8.fsf@firstfloor.org> (raw)
In-Reply-To: <4DC1C95B.4040706@gmail.com> (Dave Kleikamp's message of "Wed, 04 May 2011 16:47:07 -0500")
Dave Kleikamp <dkleikamp@gmail.com> writes:
>
> I am able to avoid this problem with either kernel parameter,
> "idle=mwait" or "processor.max_cstate=1". Similarly, defining
> CONFIG_INTEL_IDLE=y and using the kernel parameter
> intel_idle.max_cstate=1 exposes a different spinlock, pm_qos_lock, but
> I found this patch which fixes that contention:
> https://lists.linux-foundation.org/pipermail/linux-pm/2011-February/030266.html
> https://patchwork.kernel.org/patch/550721/
The pm_qos patch really needs to be merged ASAP. Len?
> Of course, we'd like to find a way to reduce the spinlock contention
> and not resort to prohibiting the cpus from entering C3 state at
> all. I don't see a simple fix, and want to know if you've seen
> anything like this before and given it any thought.
>
> I also don't know if it makes sense to be able to tune the cpuidle
> governors to add more resistance to enter the C3 state, or even being
> able to switch to a performance governor at runtime, similar to
> cpufreq.
>
> I'd like to hear your thoughts before I dive any deeper into this.
It's fixed on Westmere. There the APIC timer will always tick
and all that logic is not needed anymore and disabled.
That is mostly fixed. One problem right now is that the
CLOCK_EVT_FEAT_C3STOP test is inside the lock. But we
can easily move it out, assuming the clock_event_device
gets RCU freed or has a reference count.
But yes it would be still good to fix Nehalem too.
One fix would be to make all the masks hierarchical,
similar to what RCU does. Perhaps even some code
could be shared with RCU on that because it's a very
similar problem.
-Andi
--
ak@linux.intel.com -- Speaking for myself only
next prev parent reply other threads:[~2011-05-04 22:07 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-04 21:47 idle issues running sembench on 128 cpus Dave Kleikamp
2011-05-04 22:04 ` Thomas Gleixner
2011-05-04 22:07 ` Andi Kleen [this message]
2011-05-04 22:34 ` Thomas Gleixner
2011-05-04 23:03 ` Andi Kleen
2011-05-04 23:29 ` Thomas Gleixner
2011-05-04 23:42 ` Andi Kleen
2011-05-04 23:47 ` Thomas Gleixner
2011-05-04 23:49 ` Andi Kleen
2011-05-04 23:51 ` Thomas Gleixner
2011-05-04 23:48 ` idle issues running sembench on 128 cpus II Andi Kleen
2011-05-05 15:24 ` Dave Kleikamp
2011-05-05 13:58 ` idle issues running sembench on 128 cpus Thomas Gleixner
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=m2pqnyyva8.fsf@firstfloor.org \
--to=andi@firstfloor.org \
--cc=a.p.zijlstra@chello.nl \
--cc=chris.mason@oracle.com \
--cc=dkleikamp@gmail.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@us.ibm.com \
--cc=tglx@linutronix.de \
--cc=tim.c.chen@linux.intel.com \
/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