From owner-cvs-all@FreeBSD.ORG Wed Feb 23 20:05:50 2005 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F03A16A4CE; Wed, 23 Feb 2005 20:05:50 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B66543D58; Wed, 23 Feb 2005 20:05:50 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id j1NK5mZj000309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 23 Feb 2005 12:05:48 -0800 Message-ID: <421CE212.9030405@root.org> Date: Wed, 23 Feb 2005 12:05:38 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Maxim Sobolev References: <200502231642.j1NGgum6065193@repoman.freebsd.org> <421CD9B1.5070701@portaone.com> In-Reply-To: <421CD9B1.5070701@portaone.com> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit cc: cvs-src@FreeBSD.ORG cc: src-committers@FreeBSD.ORG cc: cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/i386/cpufreq p4tcc.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2005 20:05:50 -0000 Maxim Sobolev wrote: > Nate Lawson wrote: > >> njl 2005-02-23 16:42:56 UTC >> >> FreeBSD src repository >> >> Modified files: >> sys/i386/cpufreq p4tcc.c Log: >> Import a rewrite of p4tcc for the cpufreq(4) framework. This includes >> a bugfix of clearing the On-Demand flag when going back to 100%. It > > I don't think this counts as a bugfix, moreover I don't see any need for > additional logic to do this, since clearing on-demand flag is the same > as setting 100%. In both those cases performance is 100% and throttling > only kicks in when CPU overheats. The original p4tcc.c never cleared the On-Demand flag. Instead, it just set the 3-bit field to zero in the 100% case. I'm not sure if that worked on some systems, but on my R32, this gave the same performance as the 12.5% setting, not 100%. However, clearing the On-Demand flag did pull it back up to 100% performance, hence it was a bugfix. This matches the Intel documentation in that it only mentions the user being able to set values from 87.5% to 12.5% when On-Demand is set, no 100% value. (In other words, a setting of 0 in On-Demand mode is undefined). Here is the info from section 6.1.2 of the P4-Mobile datasheet: "When using On-Demand mode to activate the TCC, the duty cycle of the clock modulation is programmable via bits 3:1 of the same ACPI Thermal Monitor Control register. In automatic mode, the duty cycle is fixed, however in On-Demand mode, the duty cycle can be programmed from 12.5% on/ 87.5% off, to 87.5% on/12.5% off in 12.5% increments." However, this is still not perfect in that if a high thermal condition occurs, we can be at 50% performance no matter what On-Demand is set to. I added an XXX comment for this. In practice, a system that is bumping up against the Automatic thermal trip point a few seconds after boot is not going to be concerned about the announced values for cpufreq being low by 50%. -- Nate