Date: Mon, 11 Nov 2013 12:26:58 -0800 From: Adrian Chadd <adrian@freebsd.org> To: Jung-uk Kim <jkim@freebsd.org> Cc: freebsd-acpi <freebsd-acpi@freebsd.org> Subject: Re: Re: Problems with amd FX 8 core and freq scaling Message-ID: <CAJ-VmomgCyjX_tR7bLzw6s8jSJJvfB=5fXFCj6UgdKFz6rW-FQ@mail.gmail.com> In-Reply-To: <5281374F.7080802@FreeBSD.org> References: <5281358D.1010406@FreeBSD.org> <5281374F.7080802@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11 November 2013 12:00, Jung-uk Kim <jkim@freebsd.org> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 2013-11-11 13:16:47 -0500, Nicholas McKenzie wrote: >> But wouldn't this just disable frequency scaling and the whole >> point of powerd? > > No. acpi_throttle (and p4tcc) controls T-state. "Frequency scaling" > should be done by changing P-state. Right. IIRC, T-state is just for emergency temperature throttling. It shouldn't be used outside of that. >>> There have been a number of reports of throttling causing >>> crashes. This setting does not prevent powerd from adjusting >>> your CPU's clock, it just disables some arcane feature which >>> pre-dates the modern power management methods. .. did anyone ever figure out why crashes would be caused by T-state adjustment? > I rewrote acpi_throttle.c at some point to fix the problem but never > committed it because nobody was really interested in testing the > patch. Also, it is really an arcane and archaic feature: > > http://software.intel.com/en-us/blogs/2013/10/15/c-states-p-states-where-the-heck-are-those-t-states > > Now I think we should disable the feature by default because it is > causing too much hassle for us (attached). Any objection? No, I think we should correctly identify which particular features are required for which particular CPUs and enable/disable it based on that. So, if it's relevant for P4 era hardware, let's default to having it on for that class hardware. If it's not relevant for core and core 2 (and later) hardware, then let's default to leaving it off for that. So, how about we come up with a table of CPUs and what particular power save technologies we should be using, then start implementing that? I'm reading the SDM bits on the adaptive frequency stuff (turbo boost, etc) and I'll see about writing up some data gathering knobs for the kernel. People still spin up FreeBSD on P4 (and earlier) class hardware. I'd rather we get it right versus just flipping crap on and off based on what 'current' hardware expects. I watched people do this with the RTC code. It's ridiculous. -adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmomgCyjX_tR7bLzw6s8jSJJvfB=5fXFCj6UgdKFz6rW-FQ>