Re: FPS performance increase when deliberately spinning the CPU with an unrelated task

[Jesse Barnes <jbarnes@virtuousgeek.org>]

On Tue, 26 Oct 2010 01:14:04 +0100
Peter Clifton <pcjc2@cam.ac.uk> wrote:

> On Mon, 2010-10-25 at 13:20 -0700, Jesse Barnes wrote:
> > On Mon, 25 Oct 2010 13:11:24 -0700
> > Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> > 
> > > There are some bits in the GMCH to control memory behavior during CPU
> > > C-states.  Can you dump the 16 bits at MCHBAR address 0xf08?  You
> > > should be able to do that by doing I915_READ16(MCHBAR_MIRROR_BASE +
> > > 0xf08).  Assuming bits 3:2 and 1:0 are nonzero, it may help to set them
> > > all to 0.  That will disable several memory related power saving
> > > features while the CPU is in a deep sleep state.
> > 
> > Oh and bits 5:4 and bit 6 as well.  Bit 6 controls whether memory stays
> > active in C2, and bits 5:4 control which memory shutdown features are
> > enabled in C2; clearing 5:4 will disable shutdown, as will bit 6.
> 
> Is there a document somewhere which describes those? I've downloaded the
> GM45 datasheet, and it lists that address as "reserved".
> 
> FWIW. the answer is 0x730f

Ok so aggressive power saving is enabled for deep sleep states (makes
sense).  Unfortunately these bits aren't documented (even internally
it's hard to find info on this range).

> 
> (I hijacked one of the debugfs functions with this:)
> 
> 	seq_printf(m, "PCJC2 DEBUG HACK MCHBAR_MIRROR_BASE + 0xf08:        %04x\n",
> 		   I915_READ16(MCHBAR_MIRROR_BASE + 0xf08));
> 
> I trust that is correct?
> 
> Converting to bin:
> 
> 15 14 13 12 11 10  9  8  7  6  5  4  3  2  1  0
>  0  1  1  1  0  0  1  1  0  0  0  0  1  1  1  1
> 
>                             ^  ^  ^  ^  ^  ^  ^
>       Should I poke this 1? |  |__|  |__|__|__|
>       Already clear is ok?_____|              |___ Will try these at 0
> 
> 
> Just off the top of your head.. is there any way of poking these from
> userspace without reloading kernel modules?
> 
> 
> Disabling CPU frequency scaling is only half of the story, as it appears
> keeping the CPU out of C4 is the main benefit. I was checking with
> powertop when I was playing before. I don't see C2 on my machine, only
> C0, C1 and C4 (the main resident state when not working).
> 
> I understand C4 is pretty rubbish for memory usage as it disabled bus
> mastering is that what the graphics controller will require? 
> 
> Allegedly:
> 
> Your CPU supports the following C-states : C1 C2 C3 C4 C5 C6 
> Your BIOS reports the following C-states : C1 C4 
> 
> :(
> 
> 
> I'll wait your suggestions based on the above before I try poking the
> register.

You should be able to use intel_reg_write from intel-gpu-tools to poke
in the new values.

If C4 is the real issue, you can limit your c-state by booting with
cpu.max_cstate= (or is it processor.max_cstate=) at startup; that
should affect the behavior of the c-state driver.

-- 
Jesse Barnes, Intel Open Source Technology Center