Date: Wed, 5 Aug 2015 20:10:52 -0300 From: Mario Lobo <lobo@bsd.com.br> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-hackers@freebsd.org, "Herbert J. Skuhra" <herbert@oslo.ath.cx> Subject: Re: Gigabyte 970A-UD3P and hwpstate problem Message-ID: <20150805201052.4ed76a4e@Papi> In-Reply-To: <2167403.C3gzAhEsMN@ralph.baldwin.cx> References: <20150710213752.473cb831@Papi> <1678045.UlXctAKXAD@ralph.baldwin.cx> <20150805100401.265ca50f@Papi> <2167403.C3gzAhEsMN@ralph.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 05 Aug 2015 08:39:11 -0700
John Baldwin <jhb@freebsd.org> wrote:
> On Wednesday, August 05, 2015 10:04:01 AM Mario Lobo wrote:
> > On Tue, 04 Aug 2015 13:18:21 -0700
> > John Baldwin <jhb@freebsd.org> wrote:
> >
> > > On Sunday, July 12, 2015 03:23:21 PM Mario Lobo wrote:
> > > > On Sat, 11 Jul 2015 15:50:06 +0200
> > > > "Herbert J. Skuhra" <herbert@oslo.ath.cx> wrote:
> > > >
> > > > > On Fri, Jul 10, 2015 at 09:37:52PM -0300, Mario Lobo wrote:
> > > > > > Hi;
> > > > > >
> > > > > > I just installed a Gigabyte 970A-UD3P mobo and updated BIOS
> > > > > > to the latest version but the problem also showed with the
> > > > > > previous version.
> > > > > >
> > > > > > Here is my amd64 10-STABLE setup:
> > > > > >
> > > > > > FreeBSD 10.2-PRERELEASE #0 r285207M: Tue Jul 7 00:11:01 BRT
> > > > > > 2015 amd64
> > > > > >
> > > > > > CPU: AMD FX-8320E Eight-Core Processor (3214.93-MHz K8-class
> > > > > > CPU) Origin="AuthenticAMD" Id=0x600f20 Family=0x15
> > > > > > Model=0x2 Stepping=0
John;
First of all, thanks for looking into this.
> > > Can you run 'kgdb' as root and get the output of 'p amd_pminfo'?
> >
> > (kgdb) p amd_pminfo
> > $1 = 2009
>
> Ok, AMDPM_HW_PSTATE is set.
Yes!
>
> > > Hmm, do you have an acpi_perf0 device? If not, then your CPU
> > > isn't supported without BIOS help.
> >
> > No acpi_perf0 device present
>
> Ok, in that case the hwpstate driver doesn't know how to handle your
> CPU. It only has a manual fall back for older CPUs:
>
> static int
> hwpstate_get_info_from_msr(device_t dev)
> {
> ...
> switch(family) {
> case 0x11:
> /* fid/did to frequency */
> hwpstate_set[i].freq = 100 * (fid + 0x08) /
> (1 << did); break;
> case 0x10:
> /* fid/did to frequency */
> hwpstate_set[i].freq = 100 * (fid + 0x10) /
> (1 << did); break;
> default:
> HWPSTATE_DEBUG(dev, "get_info_from_msr: AMD
> family %d CPU's are not implemented yet. sorry.\n", family); return
> (ENXIO); break;
> }
> ...
> }
>
> (Your CPU is family 0x15 as you can see from dmesg.)
>
Yeah :(. Ok.
> > > First check to see if there are any BIOS
> > > options to control CPU throttling that are currently disabled.
> >
> > The only BIOS option that deals with throttling is Cool'n'Quiet,
> > which is enabled.
>
> You might try checking if C1E is enabled. Also, if you have done any
> overclocking you might try disabling that.
C1E is enable and so is C6. But, good news!
[~]>dmesg -a | grep
hwpstate hwpstate0: <Cool`n'Quiet 2.0> on cpu0
dev.hwpstate.0.freq_settings: 3200/10235 2800/8393 2300/6221 1800/4471
1400/3135 dev.cpu.0.freq_levels: 3200/10235 2800/8393 2300/6221
1800/4471 1400/3135
There was an option in the BIOS called HPC, which stands for High Power
Ccomputing (whatever that means) that, as soon as I disabled it,
hwpstate showed up. I disabled acpi_throttle and the frequencies are
still being throttled.
I must point out that the lowest frequency with acpi_throttle enabled
was 875 and now is 1400. But you were right! With hwpstate, I can see
that the temperature of the CPU is much lower, despite the fact that
the lowest frequency is higher that before, which means that hwpstate
is really more efficient.
I don't know if the list will allow it but I'm attaching a BIOS
picture.
>
> It might also be that your BIOS is not telling us about Cool N Quiet
> for some other reason. Can you get an ACPI dump?
Also attaching a zipped output of acpidump. I'll send both attachments
privately just in case the list dumps them.
>
> > I get this though:
> >
> > [~]>dmesg -a | grep acpi_
> > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0
> > acpi_button0: <Power Button> on acpi0
> > acpi_throttle0: <ACPI CPU Throttling> on cpu0
>
> As I mentioned previously, acpi_throttle is useless for you. Yes, it
> does slow your CPU down, but it doesn't save you very much power (if
> any).
>
Indeed !!
Again, thanks for helping !
--
Mario Lobo
http://www.mallavoodoo.com.br
FreeBSD since 2.2.8 [not Pro-Audio.... YET!!]
"UNIX was not designed to stop you from doing stupid things,
because that would also stop you from doing clever things."
From owner-freebsd-hackers@freebsd.org Wed Aug 5 23:48:14 2015
Return-Path: <owner-freebsd-hackers@freebsd.org>
Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
[IPv6:2001:1900:2254:206a::19:1])
by mailman.ysv.freebsd.org (Postfix) with ESMTP id 53ED19B4544
for <freebsd-hackers@mailman.ysv.freebsd.org>;
Wed, 5 Aug 2015 23:48:14 +0000 (UTC)
(envelope-from rysto32@gmail.com)
Received: from mail-io0-x235.google.com (mail-io0-x235.google.com
[IPv6:2607:f8b0:4001:c06::235])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(Client CN "smtp.gmail.com",
Issuer "Google Internet Authority G2" (verified OK))
by mx1.freebsd.org (Postfix) with ESMTPS id 1EF9F1DD2
for <freebsd-hackers@freebsd.org>; Wed, 5 Aug 2015 23:48:14 +0000 (UTC)
(envelope-from rysto32@gmail.com)
Received: by iodb91 with SMTP id b91so5363957iod.1
for <freebsd-hackers@freebsd.org>; Wed, 05 Aug 2015 16:48:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:date:message-id:subject:from:to:content-type;
bh=kX9wETTdX0GDncJG5uSkFBnUU9kHndsn+874SKHuWVk=;
b=kRJOfnCWKc/Xhq+iSvvo4rnWYZ7AiX128S5FEr2wKIuHQ98PZuIvXtkVjXNrXo2e6Q
CGgjGsEDznSTePR3WXg4qtFuSeyKnvowwbeTtlh8eiFloVjmqNBuc1ENHo3QFv5x+s/4
NNNyA97qgh+mZ8c/B9eRHUTjA4YNH4BuaTfFqpp/DQAXGm84B6XBi91+0TZBkppD7bHR
GBYe1+qzDEMXBtv+E2AupGaTMniVCEXOxGYGayUcddIY8eaEr2wFm7tg0YqukXdssjk8
SzJSBsCSa/6u+nESkdk2XwVp5NNk5XLnMnUyBDqqZShSX80K7bNotQBYuTSNpdD5fS99
dWog==
MIME-Version: 1.0
X-Received: by 10.107.157.133 with SMTP id g127mr681874ioe.102.1438818493520;
Wed, 05 Aug 2015 16:48:13 -0700 (PDT)
Received: by 10.107.169.94 with HTTP; Wed, 5 Aug 2015 16:48:13 -0700 (PDT)
Date: Wed, 5 Aug 2015 19:48:13 -0400
Message-ID: <CAFMmRNwKd7FpQBdG5C=yynSAN9o59pD-ERhZ5Z0BMykbg_Yy8Q@mail.gmail.com>
Subject: vm_lowmem is prevented every 2**31 ticks
From: Ryan Stone <rysto32@gmail.com>
To: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>
Content-Type: text/plain; charset=UTF-8
X-Content-Filtered-By: Mailman/MimeDel 2.1.20
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
<freebsd-hackers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-hackers>,
<mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers/>;
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
<mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Aug 2015 23:48:14 -0000
Currently vm_pageout_scan() uses a calculation on ticks to rate-limit the
number of vm_lowmem() events. The calculation that it uses is:
if (vmd == &vm_dom[0] && pass > 0 &&
(ticks - lowmem_ticks) / hz >= lowmem_period)
The problem with this code is that there is no guarantee that
vm_pageout_scan() will be called with pass > 0 within any time period.
This can mean that (for example) lowmem_ticks could have been 0 an
arbitrarily long time ago, and if ticks happens to be negative when we are
running low on memory, the result of ticks - lowmem_ticks will be negative
and the condition will not be true until ticks goes positive again.
A coworker suggested casting the result of the subtraction to a u_int.
This narrows the window considerably (down to 2 * lowmem_period seconds),
but it's not possible to eliminate the problem entirely as long as we use
ticks. I am tempted to just call getbintime() instead. Low memory events
should be infrequent enough that calling getbintime() should be ok.
Unless somebody has an objection or an alternate solution, I'll put
together a patch using getbintime() and get that into phabricator.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150805201052.4ed76a4e>