From owner-freebsd-stable@FreeBSD.ORG Sat Apr 9 14:14:59 2011 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3ABC9106566B; Sat, 9 Apr 2011 14:14:59 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8C61A8FC08; Sat, 9 Apr 2011 14:14:58 +0000 (UTC) Received: by bwz12 with SMTP id 12so4471244bwz.13 for ; Sat, 09 Apr 2011 07:14:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=JFNzSi9mdtGcU5AI9BavdJgvxUk8deZ7rHE6YdzmX8o=; b=Vst9iNGlNu1OJGgIdNwMYpG097rJsEU78v01HTxJxaIW43W2fxh0fkL3UqeMuu1A2i g8UVjLRKfZAvoA/CDvBuD1FY8SYTY9jCZzAnPYzcS4mFSOBgJ9J11iF2fgLgr0lAAdSy XsRAyxwNNBAprDZzv4rRXioMmMXNrKWIlT5KY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=YWm7gvRescb0DVuQ5VP3rrE4cXY5C9s/C+l840YXtAS546FBtmbPGQhPXuDjzO9eYC OwKlElMGXrcapUPp4/3hSVfyQJXlvfQ+sMZAmIDDtJ5+XsAa60Mff48KTOSwW74eElH6 t7qU+JRvZwblwqqr+mTBHqdwnlPZViq7nlmMs= Received: by 10.204.151.207 with SMTP id d15mr3192289bkw.123.1302358495539; Sat, 09 Apr 2011 07:14:55 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id q18sm2192247bka.3.2011.04.09.07.14.54 (version=SSLv3 cipher=OTHER); Sat, 09 Apr 2011 07:14:54 -0700 (PDT) Sender: Alexander Motin Message-ID: <4DA069DC.3030306@FreeBSD.org> Date: Sat, 09 Apr 2011 17:14:52 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110310 Thunderbird/3.1.9 MIME-Version: 1.0 To: Daniel Gerzo References: <4D9EEDAF.3020803@rulez.sk> <4D9EF48C.9070907@FreeBSD.org> <4D9F2384.5000104@FreeBSD.org> <85cda6f83d328e67a552b2cd5758dbd3@rulez.sk> <4D9F4B58.3050104@FreeBSD.org> <4DA01168.8050704@FreeBSD.org> In-Reply-To: <4DA01168.8050704@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@FreeBSD.org Subject: Re: powerd / cpufreq question 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: Sat, 09 Apr 2011 14:14:59 -0000 On 09.04.2011 10:57, Daniel Gerzo wrote: > On 8.4.2011 19:52, Alexander Motin wrote: >>> So, here is my attempt to implement it: >>> http://danger.rulez.sk/powerd.diff >>> Can you please review & comment? I should be able to commit it mysqlf if >>> you consider it acceptable. It seems to work for me :) >> >> Looks fine, except that -f option have to be the first, that is not >> obvious. Another moment -- I've noticed some load constants hardcoded >> there. They should also be handled to make higher values to work >> properly. > > I tried to be more explicit in the error message which tries to emphasis > the need to put it first. I don't know myself how it would be possible > to code it so that the -f doesn't need to be first. Ideas? Move checks after the loop? Just an idea. > Do you mean the values around lines of 730 - 762? Yes. When load is more the twice higher then limit - frequency rises faster. To make it work with limit > 50%, there is hardcoded additional check for 95% level. > From what I have observed, if I have a machine that is a little more > loaded (say 300%) and the load goes up, it tries to increases the > performance to quite high freq (5336) and when the load decreases again, > it takes quite a while to go down from 5366 to a frequency that is > actually available to decrease the performance (something less than > 2934). So the lower frequency is used for too short time because it > takes too much time to get it... It is intended behavior in hiadaptive mode, where performance is preferable to power-saving. >>> Seems like it was enabled by default. I have like these: >>> dev.cpu.0.cx_supported: C1/3 C2/96 C3/128 >>> >>> Does that mean I only need to set these in rc.conf?: >>> performance_cx_lowest="C3" >>> economy_cx_lowest="C3" >>> >>> Then run /etc/rc.d/power_profile 0x00? >> >> It short - yes. In long - read the link I've given. >> >>> May it cause any instability? >> >> It you won't switch from LAPIC to other timer and it stop - your system >> will freeze, or at least not work well. You should notice problems >> immediately, if there are. > > So I will also need to change the kern.timecounter.hardware to i8254? I > suppose it will cause a little less precise time, but should I expect > lower performance? I don't care that much about the time accuracy. I wasn't mentioning timecounter there. In terms of 9-CURRENT I was talking about eventtimer. In 8-STABLE it is not formalized yet and so the guide mentions number of tunables. > How do I know the C3 is active? sysctl dev.cpu.X.cx_usage > And how does it switch back to C1 for example? When CPU is idle, depending on previous idle statistics, system puts it into one of reported and allowed C-states. CPU goes back to C0 state on any hardware interrupt. -- Alexander Motin