DragonFly kernel List (threaded) for 2006-12
DragonFly BSD
DragonFly kernel List (threaded) for 2006-12
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: dual core laptop running unbearably hot


From: "Simon 'corecode' Schubert" <corecode@xxxxxxxxxxxx>
Date: Tue, 26 Dec 2006 03:20:53 +0100

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

    On a mostly idle cpu HLT will be run approximately at some multiple of
    the clock interrupt rate (since that will be the only thing interrupting
    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 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.

    I'd love an instruction like that.  I would assume that it would work for
    multi-core cpus too since it is probably based on monitoring the cache
    management bus.

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.


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



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]