DragonFly kernel List (threaded) for 2007-01
DragonFly BSD
DragonFly kernel List (threaded) for 2007-01
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: dual core laptop running unbearably hot

From: "Stephane E. Potvin" <sepotvin@xxxxxxxxxxxx>
Date: Mon, 22 Jan 2007 12:20:09 -0500

Simon 'corecode' Schubert wrote:
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


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]