dual core laptop running unbearably hot
dillon at apollo.backplane.com
Mon Dec 25 12:45:00 PST 2006
:when trying to get dragonfly running smoothly on my new core2duo laptop, i noticed that the cpu runs hot, no matter what i do (apci throttle, est). under windows this does not happen. i don't know yet about linux/other bsds, i did not yet spend so much time to investigate.
:however, something strikes me as odd: we don't HLT a cpu which is waiting for the mp lock, but instead spin for it? that seems very wrong. i think in this case we should just halt the cpu until something "new" is happening, i.e. until the mp lock becomes available or an interrupt occurs.
The scheduler should HLT in the idle loop. There is a sysctl to enable
it (on by default) and a halt counter:
sysctl -a | fgrep hlt
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.
:why do we spin when there is an IPI or an interrupt queued? why would that ever happen while in lwkt_switch? or is this just a way to process these evens in the idle thread (by preempting the idle thread as soon as it goes out of the critical secion of the lwkt scheduler)?
IPI operations only spin if the IPI software FIFO is full, and in that
case they have to spin to avoid a livelock with another cpu. But this
case almost never happens.
The scheduler doesn't really spin if it detects a pending IPI, it just
loops up and calls splz() again to process the IPI.
In the case of an interrupt being queued, its the same deal... it isn't
really spinning. It is detecting an unprocessed interrupt flag and
then processing it.
The scheduler itself spins on the MP lock or if a token cannot be
acquired. This occurs only when there is a runnable thread that needs
the MP lock or a token. The scheduler cannot HLT here because there
is no 'event' to wake the cpu out of a HLT when the MP lock or the
token is released by the other cpu. These cases do not occur very often.
:as an unrelated issue: we just have one set of global variables representing the cpu identification. i think cpus also have to be integrated into the device tree, so that we can maintain state for multiple cpus seperately (for example est has some strange notion of unique vs shared MSRs).
The first thing to check is whether the cpus are halting properly by
checking the sysctls.
ACPI's idle function is not enabled on SMP systems. Still, a normal HLT
ought to have been sufficient. I'm somewhat at a loss as to why the cpus
would be running hot.
<dillon at backplane.com>
More information about the Kernel