From owner-freebsd-hackers@freebsd.org Wed Aug 5 23:07:39 2015 Return-Path: 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 E6B879B4C5C for ; Wed, 5 Aug 2015 23:07:39 +0000 (UTC) (envelope-from lobo@bsd.com.br) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (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 6AE62D8C for ; Wed, 5 Aug 2015 23:07:38 +0000 (UTC) (envelope-from lobo@bsd.com.br) Received: by qgeh16 with SMTP id h16so41506612qge.3 for ; Wed, 05 Aug 2015 16:07:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsd.com.br; s=capeta; h=date:from:to:cc:subject:message-id:in-reply-to:references :organization:mime-version:content-type; bh=U2HLjhp56JBMGLWJYJa6KFyo/4vNRvP2B9CtIQs5TUQ=; b=CtyWK4Gvb5+c7UyfmdKtafZvLCPlN4Y6ksetAqE7+/QM84GqKwsXeMMyaTUiFMJhac QoyzjJJHS8QFA8kdWAMTtVyriz4dRk8eUhSMkTryEx0fmAWh44PtCfj+6IhXDGo6a0Gz vWbmwCk4dr/5Psu8xEqxPHsvTjQt2ntVsarbw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:organization:mime-version:content-type; bh=U2HLjhp56JBMGLWJYJa6KFyo/4vNRvP2B9CtIQs5TUQ=; b=cwQXED/Z6nJOBs4XdAw59/c4al+iE2JwLb7wwRTpOjo0tfsr1d/nOlFZoqEGg21Ebt V83d4+q21sfnv2KVlUpxCnro0WwUmvl3PiDU5cYFJWqUZ5JhGtILm8zNMmlmkEA/L+PU FvVz2pOctsD6Lz4S1J6osRGVF3BuYG1CYQpNdSLhXD4cstciIZh3vRXJ8IeVdlJgLOkx 6XU8Sb6BbmB9GZ6tazvUJAyRcYjv+VopXMVYn/DRqWc8l/uS7OjC9r4PKO/mqh+/A+xV T6DjgM97D3MI9+/0ZUWfGG0oHLfcCe1O4BqpJEl3nY0qMtaq5oDjkBxGGWLJktOh5w0D s4OA== X-Gm-Message-State: ALoCoQnNPjUzjBqtmb4qfvIeNRoP2YBwMpnlM+CqNKtn0jeyQTj/rlnpXY3cNaYfwazTsIrmB+CX X-Received: by 10.140.233.9 with SMTP id e9mr22632725qhc.71.1438816057033; Wed, 05 Aug 2015 16:07:37 -0700 (PDT) Received: from Papi ([177.98.27.21]) by smtp.gmail.com with ESMTPSA id f4sm2210131qga.5.2015.08.05.16.06.43 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Aug 2015 16:07:35 -0700 (PDT) Date: Wed, 5 Aug 2015 20:10:52 -0300 From: Mario Lobo To: John Baldwin Cc: freebsd-hackers@freebsd.org, "Herbert J. Skuhra" 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> Organization: BSD X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; amd64-portbld-freebsd10.1) MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 05 Aug 2015 23:45:41 +0000 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 23:07:40 -0000 On Wed, 05 Aug 2015 08:39:11 -0700 John Baldwin wrote: > On Wednesday, August 05, 2015 10:04:01 AM Mario Lobo wrote: > > On Tue, 04 Aug 2015 13:18:21 -0700 > > John Baldwin 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" 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: 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: on acpi0 > > acpi_throttle0: 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: 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 ; 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 ; Wed, 5 Aug 2015 23:48:14 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by iodb91 with SMTP id b91so5363957iod.1 for ; 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: Subject: vm_lowmem is prevented every 2**31 ticks From: Ryan Stone To: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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.