Re: [Intel-gfx] [PATCH 4/4] cpuidle: Hack iowait weighting to avoid C-state reduction for graphics.

Re: [Intel-gfx] [PATCH 4/4] cpuidle: Hack iowait weighting to avoid C-state reduction for graphics.

[ykzhao]

On Tue, 2010-11-02 at 04:23 +0800, Eric Anholt wrote:
> Improves nexuiz performance by about 1% on my system.

CC: Arjan and linux-acpi mailing list.

It seems that the selection of C-state will become very sensitive to IO
wait after the multi factor is changed from 10 to 1000.
Maybe only one IO/wait will bring that the system can't enter the deep
C-state.
> 
> Signed-off-by: Eric Anholt <eric@anholt.net>
> ---
>  drivers/cpuidle/governors/menu.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c
> index f508690..9bb5654 100644
> --- a/drivers/cpuidle/governors/menu.c
> +++ b/drivers/cpuidle/governors/menu.c
> @@ -175,7 +175,7 @@ static inline int performance_multiplier(void)
>  	mult += 2 * get_loadavg();
>  
>  	/* for IO wait tasks (per cpu!) we add 5x each */
> -	mult += 10 * nr_iowait_cpu(smp_processor_id());
> +	mult += 1000 * nr_iowait_cpu(smp_processor_id());
>  
>  	return mult;
>  }

Re: [PATCH 4/4] cpuidle: Hack iowait weighting to avoid C-state reduction for graphics.

[Eric Anholt]

[-- Attachment #1.1: Type: text/plain, Size: 589 bytes --]

On Tue, 02 Nov 2010 20:20:14 +0800, ykzhao <yakui.zhao@intel.com> wrote:
> On Tue, 2010-11-02 at 04:23 +0800, Eric Anholt wrote:
> > Improves nexuiz performance by about 1% on my system.
> 
> CC: Arjan and linux-acpi mailing list.
> 
> It seems that the selection of C-state will become very sensitive to IO
> wait after the multi factor is changed from 10 to 1000.
> Maybe only one IO/wait will bring that the system can't enter the deep
> C-state.

Note the original message that said "This patch series is a hack, if it
helps anyone I'll rewrite it to do the right thing".

[-- Attachment #1.2: Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/4] cpuidle: Hack iowait weighting to avoid C-state reduction for graphics.

[Alexey Fisher]

Am Dienstag, den 02.11.2010, 08:42 -0700 schrieb Eric Anholt:
> On Tue, 02 Nov 2010 20:20:14 +0800, ykzhao <yakui.zhao@intel.com> wrote:
> > On Tue, 2010-11-02 at 04:23 +0800, Eric Anholt wrote:
> > > Improves nexuiz performance by about 1% on my system.
> > 
> > CC: Arjan and linux-acpi mailing list.
> > 
> > It seems that the selection of C-state will become very sensitive to IO
> > wait after the multi factor is changed from 10 to 1000.
> > Maybe only one IO/wait will bring that the system can't enter the deep
> > C-state.
> 
> Note the original message that said "This patch series is a hack, if it
> helps anyone I'll rewrite it to do the right thing".

If this patches about perforamnce issue on 9450gm and sleep state on
CPU, than it do not work for me.

I applied your patches on the top of 3e7b033 (drm/i915: Use the agp_size
determined from the GTT), the 3/4 was rejected so id it manually.

Same result: graphic perfomence drop on smp/ht system if cpu in C4.

-- 
Regards,
        Alexey

Re: [Intel-gfx] [PATCH 4/4] cpuidle: Hack iowait weighting to avoid C-state reduction for graphics.

[Chris Wilson]

On Tue, 02 Nov 2010 21:00:31 +0100, Alexey Fisher <bug-track@fisher-privat.net> wrote:
> If this patches about perforamnce issue on 9450gm and sleep state on
> CPU, than it do not work for me.
> 
> I applied your patches on the top of 3e7b033 (drm/i915: Use the agp_size
> determined from the GTT), the 3/4 was rejected so id it manually.
> 
> Same result: graphic perfomence drop on smp/ht system if cpu in C4.

Useful check. The patches proposed should only affect readback and
throttling, when the driver is stuck waiting for the GPU with the device
mutex held. The scenario with missing vblank wakeups is that it is the
application waiting in poll for the event to be sent from the driver. In
order to have an effect, we would need to prevent the CPU from dropping
below C2? C1? whilst the vblank interrupt is unmasked i.e
drm_vblank_get(). That would also hopefully have a bigger impact on both
performance and battery life for Intel GPUs/
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre