Simon 'corecode' Schubert wrote:
quoted text
> Matthew Dillon wrote:
>> :% sysctl -a | grep -E 'cpu_idle|mplock_contention' && sleep 10 && 
>> sysctl -a | grep -E 'cpu_idle|mplock_contention'
>> :machdep.cpu_idle_hlt: 1
>> :machdep.cpu_idle_hltcnt: 6555821
>> :machdep.cpu_idle_spincnt: 42581416
>> :lwkt.mplock_contention_count: 51898977
>> :machdep.cpu_idle_hlt: 1
>> :machdep.cpu_idle_hltcnt: 6566696
>> :machdep.cpu_idle_spincnt: 42693684
>> :lwkt.mplock_contention_count: 52016936
>> :
>> :that's 1087 idle hlts, 11226 idle spins and 11795 mplock 
>> contentions.  this is on a mostly idle system.  mplock contention and 
>> idle spin counts correlate pretty well.  HLTs are executed much too 
>> seldom, though.
>>
>>     On a mostly idle cpu HLT will be run approximately at some 
>> multiple of
>>     the clock interrupt rate (since that will be the only thing 
>> interrupting
>>     the HLT).  So.  10875 (not 1087, you missed a digit) over 10 seconds
>>     is about 1000/sec.  Sounds about right.
> 
> ah, i forgot to say "per second".  if i am seeing this correctly, the 
> clock interrupt runs with 280 Hz, per cpu probably.  1000 Hz is still 
> much more, even when accounting for two CPUs.  but that's not my 
> concern.  my point is that there are 11226 idle spins per second (and 
> about equally many mplock contentions).  I think that's what is heating 
> my laptop:  busy looping on mplock/tokens.
> 
>> :>     We can't HLT when spinning on the MP lock because there will be 
>> no event
>> :>     to 'wake up' the cpu when the MP lock is released.
>> :
>> :i guess broadcasting an IPI is too slow or resource intensive.  but 
>> what i read MONITOR/MWAIT should be a possiblity to put the CPU to 
>> sleep and wake up on release (write) to the (MP)lock.  I'm not sure if 
>> MONITOR/MWAIT actually exists for dual core cpus or if it is 
>> exclusively for hyperthreading.
>>
>>     I'd love an instruction like that.  I would assume that it would 
>> work for
>>     multi-core cpus too since it is probably based on monitoring the 
>> cache
>>     management bus.
> 
> i will look into this.  we should use optimized code for this kind of 
> sleep in an abstracted way (maybe even as MI interface?) for mplock, 
> tokens and spinlocks.
> 
>>     It is always possible that I made a mistake in the coding, too, but
>>     if cpu_idle_hltcnt is being incremented it is almost certain that 
>>     cpu_idle_hook() is being called which means HLT is being called.
> 
> yes, but as you can read from my numbers there are about 1000 HLTs per 
> second and 10000 mplock contentions and spins.
> 
Hi Simon,

I'm not sure if the following will apply to DFly but the original 
FreeBSD implementation of acpi_cpu did not support the handling of the 
Cx states other than C1 when you have an SMP system. On my CoreDuo 
laptop, this also caused an unbearable temp. There is a patch that was 
merged recently into FreeBSD to acpi_cpu that fixes this (acpi_cpu.c rev 
1.60). With this patch my laptop temp is similar to the one running in 
windows.

Hope this helps

Steph