Re: Hyper mode for powerd
On Thu, 4 Jul 2013 30:12:12 -0600, Warren Block wrote:
> Attached is a proposed patch for -head that adds a "hyper" mode to powerd.
> Instead of slewing like the adaptive modes, this mode drops all the way to
> the lowest frequency when the system is idle, and jumps all the way to the
> highest frequency when there is any load.
>
> Subjectively, it seems more responsive for desktop use than hiadaptive mode.
> That's hard to benchmark. Power usage is another question. This mode might
> use less power than the adaptive modes, but that's also difficult to
> benchmark.
>
> Comments welcome.
I'll get to what Kevin talks about later, but want to address this in
the context of how most modernish systems will run without deliberate
tuning, that is with both absolute (eg est, powernow, acpi_perf) and
relative (eg p4tcc, acpi_throttle) freq drivers enabled as shipped, see
cpufreq(4) - though it may be somewhat out of date these days.
Kevin is on the money, I believe, about the relative drivers; they add
freqs of 7/8 down to 1/8 in 12.5% steps of a base absolute frequency,
but offer little or no power savings over the base freq, keep the same
CPU voltage and frequency, merely dropping between 1 and 7 out of every
8 cycles (to put it simply), by design to control excessive temperature.
cpufreq merely treats these extra frequencies as equivalent in value to
the primary, absolute levels, perhaps two to half a dozen from est /
powernow, which shift both voltage and frequency, and there's nothing
powerd can do to control - or even distinguish? - added relative freqs.
We've often seen lately freq_levels ranging from say 2400 down to 75MHz,
a range of 32:1, using the absolute levels plus all possible rates in
between from the relative drivers. It's far from an exact science, most
often I/O or network speed will be big factors, but it's perhaps fair to
speculate that a process keeping a CPU (more likely CPUs) at 75MHz let's
say 50% busy / 50% idle, is going to be something like only 1/32 as busy
cranked up to 2400MHz - maybe less than 2% busy.
Looking at your patch, 'scuse trimming and tab loss,
+ if (load > cpu_running_mark / 4) {
+ freq = freqs[0];
+ if (curfreq != freq) {
+ if (vflag) {
[..]
+ }
+ idle = 0;
+ if (set_freq(freq) != 0) {
[..]
+ }
+ }
+ } else {
+ freq = freqs[numfreqs - 1];
+ if (curfreq != freq) {
+ if (vflag) {
[..]
+ }
+ idle = 0;
+ if (set_freq(freq) != 0) {
[..]
+ }
+ }
+ }
So even if cpu_running_mark were 100% (-r100), anything busier than 25%
of our example 75MHz would shift to maximum freq immediately, where the
load will likely plummet to just a few percent, way less than the 25%
(at -r100) needed to keep it at that freq; ie it will most likely hunt.
You don't appear to be taking any notice of the -i idle percentage here;
perhaps that would be a more useful shift-down criterion? Even so, with
a full house of frequencies, I can't see this being easy to tune as is.
Show "sysctl -a | egrep 'freq|cx'" and we'll have something to chew on?
And your powerd_flags setting?
Of course anyone having a large number of freqs down to very slow could
mitigate that by setting debug.cpufreq.lowest (or powerd's -m switch) to
something more sensible, perhaps 300MHz or so, but even then it might be
wise to chose an absolute rather than relative rate. If you disable
p4tcc and throttling, you'll see how many absolute levels your CPU runs,
and you may find using only those with hadp mode satisfies your needs?
No argument this stuff is difficult to benchmark, even without the near
infinite variety of possible workload scenarios, and apart from mav@'s
power measurements with various things tuned or disabled, I've seen very
little in the way of real data over the years.
cheers, Ian
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: Hyper mode for powerd
On Sun, 7 Jul 2013, Ian Smith wrote: So even if cpu_running_mark were 100% (-r100), anything busier than 25% of our example 75MHz would shift to maximum freq immediately, where the load will likely plummet to just a few percent, way less than the 25% (at -r100) needed to keep it at that freq; ie it will most likely hunt. It may do that, but if so it's doing it more quickly than is visible running powerd -a hyper -n hyper -v. You don't appear to be taking any notice of the -i idle percentage here; perhaps that would be a more useful shift-down criterion? Even so, with a full house of frequencies, I can't see this being easy to tune as is. Show "sysctl -a | egrep 'freq|cx'" and we'll have something to chew on? And your powerd_flags setting? /boot/loader.conf: hint.p4tcc.0.disabled="1" hint.acpi_throttle.0.disabled="1" hw.acpi.cpu.cx_lowest="C3" I've routinely used the first two since first reading about them, I think in another post by Kevin. /etc/rc.conf: powerd_flags="-a hyper -n hyper" performance_cx_lowest="Cmax" performance_cpu_freq="HIGH" That grep provides a lot of unrelated "freq" stuff, so here's a guess at what you want to see: hw.acpi.cpu.cx_lowest: C8 machdep.acpi_timer_freq: 3579545 machdep.i8254_freq: 1193182 machdep.tsc_freq: 3309792585 dev.cpu.0.freq: 3601 dev.cpu.0.freq_levels: 3601/30 3600/30 3500/30 3400/30 3300/30 3200/30 3100/30 3000/30 2900/30 2800/30 2700/30 2600/30 2500/30 2400/247000 2300/224000 2200/202000 2100/182000 2000/163000 1600/91000 dev.cpu.0.cx_supported: C1/1/1 C2/2/64 C3/3/96 dev.cpu.0.cx_lowest: C8 dev.cpu.0.cx_usage: 31.99% 64.88% 3.12% last 1203us dev.cpu.1.cx_supported: C1/1/1 C2/2/64 C3/3/96 dev.cpu.1.cx_lowest: C8 dev.cpu.1.cx_usage: 37.14% 61.17% 1.68% last 11us dev.cpu.2.cx_supported: C1/1/1 C2/2/64 C3/3/96 dev.cpu.2.cx_lowest: C8 dev.cpu.2.cx_usage: 36.06% 61.83% 2.09% last 3830us dev.cpu.3.cx_supported: C1/1/1 C2/2/64 C3/3/96 dev.cpu.3.cx_lowest: C8 dev.cpu.3.cx_usage: 36.64% 61.02% 2.32% last 2us dev.est.0.freq_settings: 3601/30 3600/30 3500/30 3400/30 3300/30 3200/30 3100/30 3000/30 2900/30 2800/30 2700/30 2600/30 2500/30 2400/247000 2300/224000 2200/202000 2100/182000 2000/163000 1600/91000 dev.est.1.freq_settings: 3601/30 3600/30 3500/30 3400/30 3300/30 3200/30 3100/30 3000/30 2900/30 2800/30 2700/30 2600/30 2500/30 2400/247000 2300/224000 2200/202000 2100/182000 2000/163000 1600/91000 dev.est.2.freq_settings: 3601/30 3600/30 3500/30 3400/30 3300/30 3200/30 3100/30 3000/30 2900/30 2800/30 2700/30 2600/30 2500/30 2400/247000 2300/224000 2200/202000 2100/182000 2000/163000 1600/91000 dev.est.3.freq_settings: 3601/30 3600/30 3500/30 3400/30 3300/30 3200/30 3100/30 3000/30 2900/30 2800/30 2700/30 2600/30 2500/30 2400/247000 2300/224000 2200/202000 2100/182000 2000/163000 1600/91000 dev.cpufreq.0.%driver: cpufreq dev.cpufreq.0.%parent: cpu0 dev.cpufreq.1.%driver: cpufreq dev.cpufreq.1.%parent: cpu1 dev.cpufreq.2.%driver: cpufreq dev.cpufreq.2.%parent: cpu2 dev.cpufreq.3.%driver: cpufreq dev.cpufreq.3.%parent: cpu3 This is an i5, with the "3601" being turbo mode. ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
Re: USB ports on Lenovo T400 do not work after a suspend/resume
On Sun, 30 Jun 2013 15:02:57 -0700, Adrian Chadd wrote: > On 30 June 2013 07:22, Ian Smith wrote: [..] > > Nothing of note that I can see, if that usb hub-to-bus remapping is > > normal. As you said, 'CPU0: local APIC error 0x40' looks maybe sus. > > Maybe someone who knows might comment on that? Does noone know what that signifies? Maybe it's not relevant to this. > > Just checking: you've tried other USB devices apart from uftdi0? > > Yup, there's no 5v on the port. I was rather taken aback to hear this. Would not this indicate a failure to reinitialise the basic underlying USB hardware on resume? More than a bit bemused, Ian ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
