DragonFly kernel List (threaded) for 2007-01
Re: dual core laptop running unbearably hot
Simon 'corecode' Schubert wrote:
Matthew Dillon wrote:
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
Hope this helps
:% sysctl -a | grep -E 'cpu_idle|mplock_contention' && sleep 10 &&
sysctl -a | grep -E 'cpu_idle|mplock_contention'
: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
On a mostly idle cpu HLT will be run approximately at some
the clock interrupt rate (since that will be the only thing
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
:> 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
multi-core cpus too since it is probably based on monitoring the
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.