From owner-freebsd-acpi@FreeBSD.ORG Fri Mar 4 18:14:32 2005 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B15D216A541; Fri, 4 Mar 2005 18:14:31 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5DB4543D2F; Fri, 4 Mar 2005 18:14:31 +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 j24IEKZj009082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 4 Mar 2005 10:14:21 -0800 Message-ID: <4228A57D.9030408@root.org> Date: Fri, 04 Mar 2005 10:14:21 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Oberman References: <20050304165502.19EED5D07@ptavv.es.net> In-Reply-To: <20050304165502.19EED5D07@ptavv.es.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@FreeBSD.ORG cc: current@FreeBSD.ORG Subject: Re: patch: p4tcc and speedstep cpufreq drivers X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 18:14:32 -0000 Kevin Oberman wrote: >>Date: Thu, 03 Mar 2005 21:37:05 -0800 >>From: Nate Lawson >> >>Kevin Oberman wrote: >> >>>OK. This makes me feel a bit better, but I still think I'll leave TCC >>>out of the equation as it makes the various frequency steps vary uneven >>>to the point that lowering dev.cpu.0.freq would increase performance >>>(and the reverse, as well) and it causes my system to hang when >>>throttled back too far. It never hangs with TCC disabled although my >>>lowest "frequency" is now just 150 MHz. >> >>Would you test with hint.acpi_throttle.0.disabled="1" instead of >>disabling p4tcc? I think p4tcc is not the problem, it's the combination >>of the two. I think there are some problems when both the chipset >>(externally) and processor (internally) assert STOPCLOCK. If this works >>for you with no hangs, I'll commit code to disable acpi_throttle when >>p4tcc is present. p4tcc is more efficient than acpi_throttle since the >>latter is done through the chipset, giving more chance for race >>conditions, latency, etc. > > Looks like you are right on the button. p4tcc with throttling disabled > yields the best results I have seen. The performance is just a > little better than the "normalized" value I would expect where > throttling produced performance just a little worse. As long as I don't > run both, I don't hang at any speed and I don't get increased > performance with decreased speed. Ok, I'll commit my patch. > I really want to try some tests while actively monitoring current draw > some day, but it will require hacking on a power brick and I don't have > one I can play with at the moment. That would provide some REAL > indication of power savings with reduced performance and make tuning > more accurate. I have one we made for this purpose. Also fun on refrigerators. -- Nate