dual core laptop running unbearably hot

[Simon 'corecode' Schubert]

Matthew Dillon wrote:
: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
% 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.

    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.

: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.
then i must misinterpret these lines (lwkt_thread.c):

       } else {
           /*
            * We have nothing to run but only let the idle loop halt
            * the cpu if there are no pending interrupts.
            */
           ntd = &gd->gd_idlethread;
           if (gd->gd_reqflags & RQF_IDLECHECK_MASK)
               ntd->td_flags |= TDF_IDLE_NOHLT;
with (globaldata.h):
#define RQF_IDLECHECK_MASK      (RQF_IPIQ|RQF_INTPEND)
i think that's used to execute the queued IPIs or pending interrupts in the idle thread, right?

    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.
unfortunately, it seems they do happen very often (see numbers above).

cheers
 simon
--
Serve - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /"\
Work - Mac      +++  space for low €€€ NOW!1  +++      Campaign     \ /
Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \