From owner-freebsd-stable@FreeBSD.ORG Thu May 31 20:28:21 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 72BC2106566B; Thu, 31 May 2012 20:28:21 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C88D88FC14; Thu, 31 May 2012 20:28:20 +0000 (UTC) Message-ID: <4FC7D464.20602@FreeBSD.org> Date: Thu, 31 May 2012 16:28:20 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120502 Thunderbird/12.0.1 MIME-Version: 1.0 To: Andriy Gapon References: <1337319129.2915.4.camel@powernoodle-l7> <4FB6765A.2050307@FreeBSD.org> <1337710214.2916.8.camel@powernoodle-l7.corp.yahoo.com> <20120525163653.b61a08e2.lists@yamagi.org> <4FBFA9A9.7020806@FreeBSD.org> <4FBFBD39.7000105@FreeBSD.org> <4FBFDFFB.9020501@FreeBSD.org> <4FBFE624.1020208@FreeBSD.org> <20120526090233.f638c1d2.lists@yamagi.org> <4FC0A3A1.80200@FreeBSD.org> In-Reply-To: <4FC0A3A1.80200@FreeBSD.org> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Yamagi Burmeister , seanbru@yahoo-inc.com Subject: Re: [stable 9] broken hwpstate calls X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 20:28:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-05-26 05:34:25 -0400, Andriy Gapon wrote: > on 26/05/2012 10:02 Yamagi Burmeister said the following: >> On Fri, 25 May 2012 16:05:56 -0400 Jung-uk Kim >> wrote: >> >>>> if we decide so, then I think that we could still keep the >>>> things "simple". As we currently use the "wholesale" approach >>>> (all CPUs are set to the same P-state regardless of >>>> topology), then we could first make a pass of writing the MSR >>>> on all processors with a new P-state value and then make >>>> another pass of checking via MSR C001_0063 that the P-state >>>> is acquired. >>> >>> No, I believe checking MSRC001_0071[18:16] is much simpler if >>> it works. And it does not break current cpufreq(4) design >>> principles. >> >> Okay, thank's for your input. I'll come up with a patch. But it >> won't happen until tuesday or wednesday next week. >> > > I believe the approach that I suggested to be so trivial to > implement (and also correct) that here is a patch: ... It is simple but I don't like locking scheduler, binding CPU, and writing the same MSR, multiple times for each core. Besides, it introduces more delay and you may be reading the correct status because of that. :-P If people really think checking MSRC001_0071[18:16] is unworthy for Bulldozer, I prefer skipping status check but I disagree with this patch. Thanks, Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/H1GQACgkQmlay1b9qnVM+RQCfaYl6LpyARoO2oiyimwrWrhXD BPoAoIna4GHZKlsCRaXV3jqH8ujpzur5 =NYS0 -----END PGP SIGNATURE-----