[Bug 206961] powerd broken on SMP

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Fri Feb 5 23:42:16 UTC 2016


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206961

            Bug ID: 206961
           Summary: powerd broken on SMP
           Product: Base System
           Version: 10.2-RELEASE
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: bin
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: duraid at octopus.com.au
                CC: freebsd-amd64 at FreeBSD.org
                CC: freebsd-amd64 at FreeBSD.org

bug 125141 is marked FIXED, but I see it.

background:

2-way Xeon E5-2690 system

/etc/rc.conf: 

powerd_enable="YES"
performance_cx_lowest="Cmax"
economy_cx_lowest="Cmax"


Consider these three cases:

1) Load no CPUs

powerd works here. All cores run at reduced frequencies and enter deep sleep
states.

2) Load all CPUs

powerd works here. All cores run at high frequency and spend essentially all
time in C0. (Actually, after a couple of minutes the system (hardware) alarm
goes off because the CPUs are overheating; FreeBSD ignores that I guess, but
let's worry about that some other day...)

3) Load one CPU

Expected:

One CPU runs at maximum ("boost") frequency and spends ~100% time in C0.
(hardware-specific technicality: the core's "pair" spends 100% time in C1.)
Other cores run at minimum frequency in deep(er) sleep.

Observed:

All CPUs stay in sleep states, though all of them average frequencies >30%
above minimum. One core will average around 2% in C0 and will run at a higher
(though not maximum) frequency.



It looks like there is some serious brokenness in SMP. #125141 makes it seem
like powerd can be expected to do the right thing, but I seem to get the worst
of both worlds: increased power consumption as all cores stay out of deep sleep
and run at elevated frequencies, and decreased performance as no one core stays
in C0 running and peak frequency.

Perhaps interestingly, this problem can be exacerbated by setting
dev.cpu.<pick_one>.cx_lowest=C1 . (Which is necessary on my system to avoid USB
keyboard stuttering, but that's another issue...) It's not clear to me, then,
that this is "the same" as #125141. Maybe it is, or maybe there remains
something fundamentally wrong with powerd in (variable frequency, variable
sleep) SMP scenarios.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


More information about the freebsd-amd64 mailing list