Re: hw.setperf affects only 1 (of several) cores?

2014-12-23 Thread Marinos Yannikos
Am Di, 23. Dez 2014, um 18:10, schrieb Philip Guenther:
> On Tue, Dec 23, 2014 at 8:52 AM, Ted Unangst  wrote:
> > On Tue, Dec 23, 2014 at 12:20, Marinos Yannikos wrote:
> >  [...]
> > No, it should affect all cores.
> 
> c.f. mp_setperf_init(), as called from the mainbus_attach() routine
> after attaching bios (and thus acpi) and the cpus.

I'm still not sure why, but you're right, it does - through acpi I
presume (verified with a small program that forks n times, prints the
x2APIC id each child process is running on and times a small loop).
Apologies.

Regards,
 Marinos
-- 
  Marinos Yannikos
 m...@pobox.com



Re: hw.setperf affects only 1 (of several) cores?

2014-12-23 Thread Philip Guenther
On Tue, Dec 23, 2014 at 8:52 AM, Ted Unangst  wrote:
> On Tue, Dec 23, 2014 at 12:20, Marinos Yannikos wrote:
>> Hi,
>>
>> I believe that hw.setperf (as well as programs using it, such as apmd
>> -C) change the CPU frequency of only single (arbitrary) cores, leading
>> to higher temperatures than necessary for idle systems. It would be
>> desirable if all cores were affected.
>> (correct me if I'm wrong!)
>>
>> It doesn't seem to be easy to hack this into e.g.
>> arch/amd64/amd64/est.c since there's no way to set a CPU affinity mask
>> (only a P_CPUPEG for the scheduler, which is probably of limited use in
>> this case). Can anyone who knows the kernel code well comment / suggest
>> a course of action? A user-space implementation seems out of the
>> question too with no user-facing methods available to set CPU affinity.
>>
>
> No, it should affect all cores.

c.f. mp_setperf_init(), as called from the mainbus_attach() routine
after attaching bios (and thus acpi) and the cpus.


Philip Guenther



Re: hw.setperf affects only 1 (of several) cores?

2014-12-23 Thread Ted Unangst
On Tue, Dec 23, 2014 at 12:20, Marinos Yannikos wrote:
> Hi,
> 
> I believe that hw.setperf (as well as programs using it, such as apmd
> -C) change the CPU frequency of only single (arbitrary) cores, leading
> to higher temperatures than necessary for idle systems. It would be
> desirable if all cores were affected.
> (correct me if I'm wrong!)
> 
> It doesn't seem to be easy to hack this into e.g.
> arch/amd64/amd64/est.c since there's no way to set a CPU affinity mask
> (only a P_CPUPEG for the scheduler, which is probably of limited use in
> this case). Can anyone who knows the kernel code well comment / suggest
> a course of action? A user-space implementation seems out of the
> question too with no user-facing methods available to set CPU affinity.
>

No, it should affect all cores.



Re: hw.setperf affects only 1 (of several) cores?

2014-12-23 Thread frantisek holop
Marinos Yannikos, 23 Dec 2014 12:20:
> Practical implications: a Supermicro A1SAi based server sitting on my
> desk gets quite warm at 61°C when idle and supposedly clocked down to
> half the nominal CPU frequency at hw.setperf=0 (Linux: 43°C).

this is a difficult issue, because as far as i know,
there are no tools to query per cpu
setperf/temperature.


i was also thinking about sending an email, as i think
i see something vagualy similar on my thinkpad notebook,
but how to collect data?


in a 18C room (i like cold), i start up the notebook (not resume),
that was off all night, and it goes to 46C in a couple of minutes.
fair enough, the other notebooks in the room (3) have very
similar/same temperatures (windows and linux).

for the sake of this "scientific" experiment, i don't start
anything heavy (browser, etc), just a terminal.  every 6 minutes
or so, the temperature goes up 1C, and in 40 minutes, i am
at 53C and it will go up to 56C by the time i finish this email.

now, 50~58C are common temperatures for common usage on
a common notebook.  but this room is 18C, and the
notebook is basically idle. (i will also boot linux on
it later to compare)

it seems to me, that at 18C, an idle CPU at 1000MHz
should be around 45~48C.


resume is a whole other thing.  in a 18C room, after
a whole night of being off, temperature goes into the
high 60s and early 70C right away and it is clear
it should be at least 20 less.  but i was trying to
get more data on this for a bug report.

-f


$ sysctl hw
hw.machine=i386
hw.model=Intel(R) Core(TM) Duo CPU L2400 @ 1.66GHz ("GenuineIntel" 686-class)
hw.ncpu=2
hw.byteorder=1234
hw.pagesize=4096
hw.disknames=sd0:2a6c0cb2b714a4f0,sd1:9b35dfa2af509654
hw.diskcount=2
hw.sensors.acpitz0.temp0=52.00 degC (zone temperature)
hw.sensors.acpitz1.temp0=53.00 degC (zone temperature)
hw.sensors.acpibtn0.indicator0=On (lid open)
hw.sensors.acpibat0.volt0=14.40 VDC (voltage)
hw.sensors.acpibat0.volt1=16.65 VDC (current voltage)
hw.sensors.acpibat0.power0=0.00 W (rate)
hw.sensors.acpibat0.watthour0=23.71 Wh (last full capacity)
hw.sensors.acpibat0.watthour1=1.19 Wh (warning capacity)
hw.sensors.acpibat0.watthour2=0.20 Wh (low capacity)
hw.sensors.acpibat0.watthour3=23.71 Wh (remaining capacity), OK
hw.sensors.acpibat0.watthour4=28.80 Wh (design capacity)
hw.sensors.acpibat0.raw0=0 (battery full), OK
hw.sensors.acpiac0.indicator0=On (power supply)
hw.sensors.acpithinkpad0.temp0=52.00 degC
hw.sensors.acpithinkpad0.temp1=42.00 degC
hw.sensors.acpithinkpad0.temp3=49.00 degC
hw.sensors.acpithinkpad0.temp4=18.00 degC
hw.sensors.acpithinkpad0.temp6=18.00 degC
hw.sensors.acpithinkpad0.fan0=3011 RPM
hw.sensors.acpidock0.indicator0=Off (not docked), UNKNOWN
hw.sensors.cpu0.temp0=53.00 degC
hw.sensors.aps0.temp0=42.00 degC
hw.sensors.aps0.temp1=42.00 degC
hw.sensors.aps0.indicator0=On (Keyboard Active)
hw.sensors.aps0.indicator1=Off (Mouse Active)
hw.sensors.aps0.indicator2=On (Lid Open)
hw.sensors.aps0.raw0=466 (X_ACCEL)
hw.sensors.aps0.raw1=511 (Y_ACCEL)
hw.sensors.aps0.raw2=466 (X_VAR)
hw.sensors.aps0.raw3=511 (Y_VAR)
hw.sensors.softraid0.drive0=online (sd1), OK
hw.cpuspeed=1000
hw.setperf=0
hw.vendor=LENOVO
hw.product=1705CTO
hw.version=ThinkPad X60s
hw.serialno=LVB7000
hw.uuid=b3bcd5e0-08e3-11dc-9e40-c19b215ac37f
hw.physmem=2137341952
hw.usermem=2111606784
hw.ncpufound=2
hw.allowpowerdown=1
hw.perfpolicy=auto


OpenBSD 5.6-current (GENERIC.MP) #630: Thu Dec 18 01:03:03 MST 2014
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Core(TM) Duo CPU L2400 @ 1.66GHz ("GenuineIntel" 686-class) 1.67 
GHz
cpu0: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM,PERF
real mem  = 2137341952 (2038MB)
avail mem = 2090070016 (1993MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 03/31/11, BIOS32 rev. 0 @ 0xfd690, SMBIOS 
rev. 2.4 @ 0xe0010 (67 entries)
bios0: vendor LENOVO version "7BETD8WW (2.19 )" date 03/31/2011
bios0: LENOVO 1705CTO
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT ECDT TCPA APIC MCFG HPET SLIC BOOT SSDT SSDT SSDT 
SSDT
acpi0: wakeup devices LID_(S3) SLPB(S3) DURT(S3) EXP0(S4) EXP1(S4) EXP2(S4) 
EXP3(S4) PCI1(S4) USB0(S3) USB1(S3) USB2(S3) USB7(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 166MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) Duo CPU L2400 @ 1.66GHz ("GenuineIntel" 686-class) 1.67 
GHz
cpu1: 
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM,PERF
ioapic0 at mainbus0: apid 1 pa 0x