From: Len Brown <lenb@kernel.org>
To: "Yung, Winson W" <winson.w.yung@intel.com>
Cc: Venkatesh Pallipadi <venki@google.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Van De Ven, Arjan" <arjan.van.de.ven@intel.com>,
"Kanigeri, Hari K" <hari.k.kanigeri@intel.com>
Subject: RE: [PATCH] [RFC] ondemand governor: dynamic cpufreq scaling with different CPUs
Date: Mon, 01 Aug 2011 10:51:38 -0400 (EDT) [thread overview]
Message-ID: <alpine.LFD.2.02.1108011033540.23581@x980> (raw)
In-Reply-To: <CAC4B8726E86A142B27A9E9A2F2F124701921EF878@rrsmsx505.amr.corp.intel.com>
Re: software vs hardware coordination
Speaking for Intel, everything we make, from hand-sets to supercomputers
supports hardware coorination.
Think about it -- if we did not, then we would not be able
to support a legacy OS that doesn't know how to do SW coordination.
HW coordiation is the simplest thing for the SW because
SW doesn't have to know anything at all about topology constraints.
It is also the simplest thing for the BIOS, which doesn't have
to correctly describe topology.
Yes, there is an MSR bit that the BIOS can flip to disable
HW coordination. 90% of the time that bit is set it is a BIOS bug.
eg. the bit is set, but the BIOS fails to properly set up the
ACPI tables to properly enable SW coordination, resulting
in a system with really strange performance issues.
Indeed, I proposed before, and I will propose again that
the underlying ACPI _PSD support behind SW coordination
be completely removed from Linux.
Venki,
I recall that you mentioned one platform that depends on it --
and I'd like to understand that issue and address it with a quirk
rather than expose all systems to BIOS bugs due to bogus _PSD support.
Winston,
Your system is running in SW coordination mode?
What do you see if you run with the patch below?
I'd be intersted to see the output from adpidump for your system.
thanks,
-Len Brown
Intel Open Source Technology Center
---
diff --git a/include/acpi/pdc_intel.h b/include/acpi/pdc_intel.h
index 552637b..d081595 100644
--- a/include/acpi/pdc_intel.h
+++ b/include/acpi/pdc_intel.h
@@ -22,7 +22,6 @@
#define ACPI_PDC_EST_CAPABILITY_SWSMP (ACPI_PDC_SMP_C1PT | \
ACPI_PDC_C_C1_HALT | \
- ACPI_PDC_SMP_P_SWCOORD | \
ACPI_PDC_SMP_P_HWCOORD | \
ACPI_PDC_P_FFH)
next prev parent reply other threads:[~2011-08-01 15:52 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-26 17:22 Yung, Winson W
2011-07-29 16:52 ` Venkatesh Pallipadi
2011-08-01 1:08 ` Yung, Winson W
2011-08-01 14:51 ` Len Brown [this message]
2011-08-10 16:59 ` Venki Pallipadi
2011-08-10 17:05 ` Venki Pallipadi
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=alpine.LFD.2.02.1108011033540.23581@x980 \
--to=lenb@kernel.org \
--cc=arjan.van.de.ven@intel.com \
--cc=hari.k.kanigeri@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=venki@google.com \
--cc=winson.w.yung@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
all inboxes | Powered by JetHome®