Re: dual core laptop running unbearably hot

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:hey,
:
: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).
:
:cheers
:  simon

    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.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>