Re: dual core laptop running unbearably hot

["Simon 'corecode' Schubert" <corecode@xxxxxxxxxxxx>]

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   / \