DragonFly commits List (threaded) for 2007-07
DragonFly BSD
DragonFly commits List (threaded) for 2007-07
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: cvs commit: src/sys/kern kern_spinlock.c src/sys/platform/vkernel/i386 cpu_regs.c src/sys/sys systm.h src/sys/platform/pc32/i386 machdep.c

From: Michal Belczyk <belczyk@xxxxxxxxxxxxx>
Date: Mon, 2 Jul 2007 23:30:19 +0200

On Mon, Jul 02, 2007 at 11:07:39PM +0200, Simon 'corecode' Schubert wrote:
>  Michal Belczyk wrote:
> > On Mon, Jul 02, 2007 at 07:06:21PM +0200, Simon 'corecode' Schubert wrote:
> >> Matthew Dillon wrote:
> >>>   Log:
> >>>   Implement an architecture call for contended spinlocks so the vkernel 
> >>> can
> >>>   insert a usleep().
> >> Very nice.  I've been meaning to do this.  We could use monitor/mwait on 
> >> core2duo CPUs for power reduction for example (also when waiting for the 
> >> mplock/scheduler changes in the idle loop).
> > On my core2duo laptop replacing cpu_idle_hook() with one using mwait to 
> > enter
> > enhanced halt states resulted in lowering the maximal cpu temperature from
> > above 60 to below 55 degrees and made the cpu fan run less often.  I even 
> > made
> > some graphs representing the cpu temperature in time[1] on an idle system.
>  Wow.  Then I must have missunderstood the Intel docs.  I thought "hlt" was 
>  as low as it can get, now you tell me hlt is less efficient than mwait?  We 
>  definitely need that.  However, we need some way to dynamically use one or 
>  the other system, depending on CPU features.  Binary runtime patching comes 
>  to my mind...

HLT only puts the cpu into C1 state whereas MWAIT can bring it into so-called
enhanced halt states -- C1E, C2E, ... -- where cpu tries to decrease its
freqency.  As you can see on the graphs putting the cpu into something >= C3
requires some PCI-foo which I'm not aware of to make it.

> > However, I believe that lowering cpu voltage and frequency via EST and estd
> > should give better results.  Some time ago I wrote a kernel module
> > implementing EST for those cpus[2] in an ACPI-independent way.
>  How does this differ from the common way of doing EST (writing to the MSRS)?

It doesn't but on multicore cpus it requires synchronization between cores and
well... it's not well documented.  The module I sent link to is an effect of
my own experiments at Narita airport on my way back home from AsiaBSDCon ;-)

> > Nice thing is
> > that one can set voltage and frequency idependently of each other, at least 
> > on
> > my cpu ;-)  And it was working with estd.
>  This actually worked (more as a bug) with the est module as well (always 
>  operating on the current core).  However, I could not see any benefit 
>  setting a lower frequency/voltage:  The CPU would run slower, but the fan 
>  would turn on equally often.

The fan is another thing to control -- e.g. all the ThinkPads suffer from
badly programmed embedded controller which is responsible for how it works.
Anyway, estd should change the frequency depending on system load.  I tried it
on my laptop simply by running make buildworld and it worked as expected.

> > Now it's probably non-compilable
> > after some SYSINIT-related macros had been renamed.
> > Note that it's based only on intel docs and my own experiments so there 
> > might
> > be bugs in it.
>  It would be really awesome if you maybe could find the time to integrate 
>  this into the sources and submit a patch, as you have already considerable 
>  experience.  Do you think this might be possible?

Sure it's possible! :-)
I'll work on it and send patches.  Have you got some core2duo machine to test
it before I post it to the submit list?

Michal Belczyk

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