[RFC] Hack to avoid C-state reduction during graphics activity.

[RFC] Hack to avoid C-state reduction during graphics activity.

[Eric Anholt]

This is a series I came up with as a result of KS discussions.  The
plan was to pin the CPU C state to keep the GPU going as fast as
possible while it was active, since there's some relation between the
two (we don't know for sure yet, per chipset, whether it's due to
latency of DMA writes having to bring CPU state up, or reduced memory
bandwidth due to bus frequency reduction, or other).  The actual patch
series doesn't achieve that -- a hint is provided to the scheduler and
cpufreq/cpuidle, which may choose not to sleep as deeply as it would
otherwise.

I found a 1% performance difference in nexuiz on my Ironlake system
from the last patch in this series (HEAD~1 didn't have a statistically
significant effect).  If that's all the difference, I'll drop this.
It may pay off higher for non-Ironlake, in which case I'll work on a
"proper" solution of actually clamping C-states while graphics is
active.

[PATCH 1/4] sched: Export io_schedule_timeout()

[Eric Anholt]

This is the logical partner to the already exported io_schedule() and
schedule_timeout(), and will be used by the DRM.

Signed-off-by: Eric Anholt <eric@anholt.net>
---
 kernel/sched.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/kernel/sched.c b/kernel/sched.c
index aa14a56..ec853f9 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -5287,6 +5287,7 @@ long __sched io_schedule_timeout(long timeout)
 	delayacct_blkio_end();
 	return ret;
 }
+EXPORT_SYMBOL(io_schedule_timeout);
 
 /**
  * sys_sched_get_priority_max - return maximum RT priority.
-- 
1.7.2.3

[PATCH 2/4] Add io_ variants of wait_event() and wait_event_interruptible()

[Eric Anholt]

These tell the scheduler that we're waiting on IO, and still "busy".

Signed-off-by: Eric Anholt <eric@anholt.net>
---
 include/linux/wait.h |   46 ++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 46 insertions(+), 0 deletions(-)

diff --git a/include/linux/wait.h b/include/linux/wait.h
index 3efc9f3..b299c2b 100644
--- a/include/linux/wait.h
+++ b/include/linux/wait.h
@@ -202,6 +202,19 @@ do {									\
 	finish_wait(&wq, &__wait);					\
 } while (0)
 
+#define __io_wait_event(wq, condition) 					\
+do {									\
+	DEFINE_WAIT(__wait);						\
+									\
+	for (;;) {							\
+		prepare_to_wait(&wq, &__wait, TASK_UNINTERRUPTIBLE);	\
+		if (condition)						\
+			break;						\
+		io_schedule();						\
+	}								\
+	finish_wait(&wq, &__wait);					\
+} while (0)
+
 /**
  * wait_event - sleep until a condition gets true
  * @wq: the waitqueue to wait on
@@ -221,6 +234,13 @@ do {									\
 	__wait_event(wq, condition);					\
 } while (0)
 
+#define io_wait_event(wq, condition) 					\
+do {									\
+	if (condition)	 						\
+		break;							\
+	__io_wait_event(wq, condition);					\
+} while (0)
+
 #define __wait_event_timeout(wq, condition, ret)			\
 do {									\
 	DEFINE_WAIT(__wait);						\
@@ -260,6 +280,24 @@ do {									\
 	__ret;								\
 })
 
+#define __io_wait_event_interruptible(wq, condition, ret)		\
+do {									\
+	DEFINE_WAIT(__wait);						\
+									\
+	for (;;) {							\
+		prepare_to_wait(&wq, &__wait, TASK_INTERRUPTIBLE);	\
+		if (condition)						\
+			break;						\
+		if (!signal_pending(current)) {				\
+			io_schedule();					\
+			continue;					\
+		}							\
+		ret = -ERESTARTSYS;					\
+		break;							\
+	}								\
+	finish_wait(&wq, &__wait);					\
+} while (0)
+
 #define __wait_event_interruptible(wq, condition, ret)			\
 do {									\
 	DEFINE_WAIT(__wait);						\
@@ -301,6 +339,14 @@ do {									\
 	__ret;								\
 })
 
+#define io_wait_event_interruptible(wq, condition)			\
+({									\
+	int __ret = 0;							\
+	if (!(condition))						\
+		__io_wait_event_interruptible(wq, condition, __ret);	\
+	__ret;								\
+})
+
 #define __wait_event_interruptible_timeout(wq, condition, ret)		\
 do {									\
 	DEFINE_WAIT(__wait);						\
-- 
1.7.2.3

[PATCH 3/4] drm/i915: Declare waits on GPU as io waits, to reduce C-state reduction.

[Eric Anholt]

Because of this, the C-state governor will consider our process
"performance critical" and avoid dropping CPU power during these
temporary sleeps.  There are two benefits of this: We don't lose our
cache contents (whose value is not well reflected in the metrics of
the governor), and also don't reduce memory bandwidth, which can
reduce GPU performance and increase the time we wait!

Signed-off-by: Eric Anholt <eric@anholt.net>
---
 drivers/gpu/drm/i915/i915_gem.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8eb8453..8991588 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1988,12 +1988,12 @@ i915_do_wait_request(struct drm_device *dev, uint32_t seqno,
 		ring->waiting_gem_seqno = seqno;
 		ring->user_irq_get(dev, ring);
 		if (interruptible)
-			ret = wait_event_interruptible(ring->irq_queue,
+			ret = io_wait_event_interruptible(ring->irq_queue,
 				i915_seqno_passed(
 					ring->get_seqno(dev, ring), seqno)
 				|| atomic_read(&dev_priv->mm.wedged));
 		else
-			wait_event(ring->irq_queue,
+			io_wait_event(ring->irq_queue,
 				i915_seqno_passed(
 					ring->get_seqno(dev, ring), seqno)
 				|| atomic_read(&dev_priv->mm.wedged));
-- 
1.7.2.3

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

[Eric Anholt]

Improves nexuiz performance by about 1% on my system.

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;
 }
-- 
1.7.2.3

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

Re: [RFC] Hack to avoid C-state reduction during graphics activity.

[Andrew Lutomirski]

Out of curiousity, what happened to ACPI_BM_BREAK_EN here:

https://bugs.freedesktop.org/show_bug.cgi?id=30364

On my box, that register is (according to setpci) 0x00, but I'm
testing on an ICH9M and I don't seem to be affected anyway.

--Andy



On Mon, Nov 1, 2010 at 4:23 PM, Eric Anholt <eric@anholt.net> wrote:
> This is a series I came up with as a result of KS discussions.  The
> plan was to pin the CPU C state to keep the GPU going as fast as
> possible while it was active, since there's some relation between the
> two (we don't know for sure yet, per chipset, whether it's due to
> latency of DMA writes having to bring CPU state up, or reduced memory
> bandwidth due to bus frequency reduction, or other).  The actual patch
> series doesn't achieve that -- a hint is provided to the scheduler and
> cpufreq/cpuidle, which may choose not to sleep as deeply as it would
> otherwise.
>
> I found a 1% performance difference in nexuiz on my Ironlake system
> from the last patch in this series (HEAD~1 didn't have a statistically
> significant effect).  If that's all the difference, I'll drop this.
> It may pay off higher for non-Ironlake, in which case I'll work on a
> "proper" solution of actually clamping C-states while graphics is
> active.
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>

Re: [RFC] Hack to avoid C-state reduction during graphics activity.

[Eric Anholt]

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

On Mon, 1 Nov 2010 17:00:46 -0400, Andrew Lutomirski <luto@mit.edu> wrote:
> Out of curiousity, what happened to ACPI_BM_BREAK_EN here:
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=30364
> 
> On my box, that register is (according to setpci) 0x00, but I'm
> testing on an ICH9M and I don't seem to be affected anyway.

Those registers aren't there on Ironlake.

[-- 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