Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1272310 > unrolled thread

Re: [PATCH 3/4] sched: introduce synchronized idle injection

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 3/4] sched: introduce synchronized idle injection Morten Rasmussen <morten.rasmussen@arm.com> - 2015-11-18 16:50 +0100
    Re: [PATCH 3/4] sched: introduce synchronized idle injection Arjan van de Ven <arjan@linux.intel.com> - 2015-11-18 17:00 +0100
      Re: [PATCH 3/4] sched: introduce synchronized idle injection Morten Rasmussen <morten.rasmussen@arm.com> - 2015-11-19 18:30 +0100
        Re: [PATCH 3/4] sched: introduce synchronized idle injection Peter Zijlstra <peterz@infradead.org> - 2015-11-19 21:10 +0100
          Re: [PATCH 3/4] sched: introduce synchronized idle injection Thomas Gleixner <tglx@linutronix.de> - 2015-11-20 10:50 +0100
            Re: [PATCH 3/4] sched: introduce synchronized idle injection Peter Zijlstra <peterz@infradead.org> - 2015-11-20 11:30 +0100
              Re: [PATCH 3/4] sched: introduce synchronized idle injection Thomas Gleixner <tglx@linutronix.de> - 2015-11-20 12:00 +0100
                Re: [PATCH 3/4] sched: introduce synchronized idle injection Peter Zijlstra <peterz@infradead.org> - 2015-11-20 14:00 +0100
                  Re: [PATCH 3/4] sched: introduce synchronized idle injection Thomas Gleixner <tglx@linutronix.de> - 2015-11-20 20:00 +0100
                Re: [PATCH 3/4] sched: introduce synchronized idle injection Jacob Pan <jacob.jun.pan@linux.intel.com> - 2015-11-24 12:40 +0100
        Re: [PATCH 3/4] sched: introduce synchronized idle injection Jacob Pan <jacob.jun.pan@linux.intel.com> - 2015-11-23 19:00 +0100

#1272310 — Re: [PATCH 3/4] sched: introduce synchronized idle injection

On Fri, Nov 13, 2015 at 11:53:06AM -0800, Jacob Pan wrote:
> With increasingly constrained power and thermal budget, it's often
> necessary to cap power via throttling. Throttling individual CPUs
> or devices at random times can help power capping but may not be
> optimal in terms of energy efficiency. Frequency scaling is also
> limited by certain range before losing energy efficiency.
> 
> In general, the optimal solution in terms of energy efficiency is
> to align idle periods such that more shared circuits can be power
> gated to enter lower power states. Combined with energy efficient
> frequency point, idle injection provides a way to scale power and
> performance efficiently.
> 
> This patch introduces a scheduler based idle injection method, it
> works by blocking CFS runqueue synchronously and periodically. The
> actions on all online CPUs are orchestrated by per CPU hrtimers.

I fully agree with the idea of synchronous duty cycling of cpus for
thermal management to avoid those inefficient low frequencies where we
loose a lot of energy to static power consumption and get very little
work done. However, I would not necessarily want to punish all cpus
system-wide if we have local overheating in one corner. If would rather
have it apply to only the overheating socket in a multi-socket machine
and only the big cores in a big.LITTLE system.

Several people have already brought up that we should look into
integrating this with the thermal framework. It already has the concepts
of thermal zones and cooling devices which could be used to control
idle-injection separately for different sockets/clusters.

Also, letting user-space control idle-injection opens up for having two
entities (user-space daemon and the in-kernel thermal governor) stepping
on each others toes. Wouldn't the control of idle-injection naturally
belong to thermal governors so we have everything controlled from a
single place?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1272329

On 11/18/2015 7:44 AM, Morten Rasmussen wrote:
> I would not necessarily want to punish all cpus
> system-wide if we have local overheating in one corner. If would rather
> have it apply to only the overheating socket in a multi-socket machine
> and only the big cores in a big.LITTLE system.

most of the time thermal issues aren't inside the SOC, but on a system level
due to cheap heat spreaders or outright lack of space due to thinness. But
even if you have one part of the die too hot:

For core level idle injection, no need to synchronize that; the reason to synchronize
is generally that when ALL cores are idle, additional power savings kick in
(like memory going to self refresh, fabrics power gating etc); those additional
power savings are what makes this more efficient than just voltage/frequency
scaling at the bottom of that range...   not so much the fact that things are just idle.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1273300

On Wed, Nov 18, 2015 at 07:51:47AM -0800, Arjan van de Ven wrote:
> On 11/18/2015 7:44 AM, Morten Rasmussen wrote:
> >I would not necessarily want to punish all cpus
> >system-wide if we have local overheating in one corner. If would rather
> >have it apply to only the overheating socket in a multi-socket machine
> >and only the big cores in a big.LITTLE system.
> 
> most of the time thermal issues aren't inside the SOC, but on a system level
> due to cheap heat spreaders or outright lack of space due to thinness. But
> even if you have one part of the die too hot:
> 
> For core level idle injection, no need to synchronize that; the reason to synchronize
> is generally that when ALL cores are idle, additional power savings kick in
> (like memory going to self refresh, fabrics power gating etc); those additional
> power savings are what makes this more efficient than just voltage/frequency
> scaling at the bottom of that range...   not so much the fact that things are just idle.

I could see this technique being useful within the SoC as well.
Synchronized idle injection on all cpus in a cluster would allow us to
reach cluster idle states where resources shared within the cluster can
be gated or powered off as well. But yes, shutting down everything is
more efficient if you are en serious trouble.

I was hoping this could be a good alternative to hotplugging cpus out
for thermal management in non-critical situations, but it isn't that
appealing if you have to throttle all the cpus. I would consider it an
emergency-only mechanism (as in emergency brake) that isn't really
suitable for normal thermal management. In which case: Does this sort of
mechanism belong in the scheduler code?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1273445

On Thu, Nov 19, 2015 at 05:24:07PM +0000, Morten Rasmussen wrote:
> I would consider it an
> emergency-only mechanism (as in emergency brake) that isn't really
> suitable for normal thermal management. In which case: Does this sort of
> mechanism belong in the scheduler code?

I would prefer it not to be, but Thomas is very much opposed to teaching
the nohz code to 'work' on !idle threads.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1273897

On Thu, 19 Nov 2015, Peter Zijlstra wrote:
> On Thu, Nov 19, 2015 at 05:24:07PM +0000, Morten Rasmussen wrote:
> > I would consider it an
> > emergency-only mechanism (as in emergency brake) that isn't really
> > suitable for normal thermal management. In which case: Does this sort of
> > mechanism belong in the scheduler code?
> 
> I would prefer it not to be, but Thomas is very much opposed to teaching
> the nohz code to 'work' on !idle threads.

The whole concept of faking idle is simply crap.

If you want to avoid that stuff in the scheduler, then create a
mechanism which just defers the next timer interrupt for X
milliseconds and does not any fiddling with NOHZ state and such.

That might hurt RT tasks, but if someone really cares about real-time
and deterministic behaviour, then running the machine on its thermal
limits is simply stupid. In fact any sensible RT system will bring
itself into a safe state way before the machine runs into that
condition.

Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1273950

On Fri, Nov 20, 2015 at 10:45:14AM +0100, Thomas Gleixner wrote:

> The whole concept of faking idle is simply crap.

:-)

> If you want to avoid that stuff in the scheduler, then create a
> mechanism which just defers the next timer interrupt for X
> milliseconds and does not any fiddling with NOHZ state and such.

Not sure that will actually result in the machine going idle. Device
interrupts will still wake tasks and get them ran.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1273979

On Fri, 20 Nov 2015, Peter Zijlstra wrote:

> On Fri, Nov 20, 2015 at 10:45:14AM +0100, Thomas Gleixner wrote:
> 
> > The whole concept of faking idle is simply crap.
> 
> :-)
> 
> > If you want to avoid that stuff in the scheduler, then create a
> > mechanism which just defers the next timer interrupt for X
> > milliseconds and does not any fiddling with NOHZ state and such.
> 
> Not sure that will actually result in the machine going idle. Device
> interrupts will still wake tasks and get them ran.

That's not what I meant. If you don't want to control all that from
the scheduler than you are back to that thread which "runs" at RT
priority and does

	 if (machine_on_fire) {
	        defer_timer_interrupt(5ms);
		end = now + 5ms:
	    	while (now < end)
		      mwait();
         }

That's what the existing code does, but the above does not longer
claim it's idle and confuses the hell out of nohz and whatever.  It's
just a "runaway" RT task which "hogs" the CPU for 5ms and makes the
next timer interrupt firing late.

Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1274057

On Fri, Nov 20, 2015 at 11:58:12AM +0100, Thomas Gleixner wrote:
> That's not what I meant. If you don't want to control all that from
> the scheduler than you are back to that thread which "runs" at RT
> priority and does
> 
> 	 if (machine_on_fire) {
> 	        defer_timer_interrupt(5ms);
> 		end = now + 5ms:
> 	    	while (now < end)
> 		      mwait();
>          }
> 
> That's what the existing code does, but the above does not longer
> claim it's idle and confuses the hell out of nohz and whatever.  It's
> just a "runaway" RT task which "hogs" the CPU for 5ms and makes the
> next timer interrupt firing late.

Right; so the naive way of implementing that is by simply programing the
timer hardware 5ms in the future and leaving it at that.

The problem with that would be a device interrupt happening and mucking
with timers, this would result in the timer hardware being reprogrammed
to a 'sane' value. I see two solutions for that:

 - add another check in tick_program_event(); or,

 - muck about with the evtdev pointer, such that we (temporarily) neuter
   its clock_event_device::set_next_*() methods.

The later is fugly, but avoids any runtime overhead.

This all makes the idle-injection muck hard depend on hres_active, but I
think that's a sane constraint anyway.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1274354

On Fri, 20 Nov 2015, Peter Zijlstra wrote:
> On Fri, Nov 20, 2015 at 11:58:12AM +0100, Thomas Gleixner wrote:
> > That's not what I meant. If you don't want to control all that from
> > the scheduler than you are back to that thread which "runs" at RT
> > priority and does
> > 
> > 	 if (machine_on_fire) {
> > 	        defer_timer_interrupt(5ms);
> > 		end = now + 5ms:
> > 	    	while (now < end)
> > 		      mwait();
> >          }
> > 
> > That's what the existing code does, but the above does not longer
> > claim it's idle and confuses the hell out of nohz and whatever.  It's
> > just a "runaway" RT task which "hogs" the CPU for 5ms and makes the
> > next timer interrupt firing late.
> 
> Right; so the naive way of implementing that is by simply programing the
> timer hardware 5ms in the future and leaving it at that.
> 
> The problem with that would be a device interrupt happening and mucking
> with timers, this would result in the timer hardware being reprogrammed
> to a 'sane' value. I see two solutions for that:
> 
>  - add another check in tick_program_event(); or,
> 
>  - muck about with the evtdev pointer, such that we (temporarily) neuter
>    its clock_event_device::set_next_*() methods.
> 
> The later is fugly, but avoids any runtime overhead.

Yes, it's fugly, but it does not touch any of the states.
 
> This all makes the idle-injection muck hard depend on hres_active, but I
> think that's a sane constraint anyway.

It makes it actually depend on NO_HZ || HRES. It comes with a few
other restrictions as well: I'm not going to support that for TSCs
which stop in C3. It's ugly enough already and I really don't want to
muck with the broadcast device.

One other thing is that the caller has to ensure that the unblock()
happens in a timely manner. I really would recommend to just disable
preemption around that machine on fire wait loop and screw the RT
tasks. We screw them anyway when they depend on a timer.

Untested patch below.

Thanks,

	tglx

8<----------------
Subject: tick/nohz: Allow blocking the tick to prevent fire
From: Thomas Gleixner <tglx@linutronix.de>
Date: Fri, 20 Nov 2015 14:28:17 +0100

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
 include/linux/tick.h     |    5 ++
 kernel/time/Kconfig      |    5 ++
 kernel/time/tick-sched.c |   99 +++++++++++++++++++++++++++++++++++++++++++++++
 kernel/time/tick-sched.h |    7 ++-
 4 files changed, 114 insertions(+), 2 deletions(-)

Index: tip/include/linux/tick.h
===================================================================
--- tip.orig/include/linux/tick.h
+++ tip/include/linux/tick.h
@@ -203,4 +203,9 @@ static inline void tick_nohz_task_switch
 		__tick_nohz_task_switch();
 }
 
+#ifdef CONFIG_TICK_THROTTLING
+int tick_nohz_block_tick(u64 delay);
+void tick_nohz_unblock_tick(void);
+#endif
+
 #endif
Index: tip/kernel/time/Kconfig
===================================================================
--- tip.orig/kernel/time/Kconfig
+++ tip/kernel/time/Kconfig
@@ -60,6 +60,11 @@ menu "Timers subsystem"
 config TICK_ONESHOT
 	bool
 
+# Special functions for tick throttling to avoid fire extinguishers
+config TICK_THROTTLING
+       bool
+       depends on TICK_ONESHOT
+
 config NO_HZ_COMMON
 	bool
 	depends on !ARCH_USES_GETTIMEOFFSET && GENERIC_CLOCKEVENTS
Index: tip/kernel/time/tick-sched.c
===================================================================
--- tip.orig/kernel/time/tick-sched.c
+++ tip/kernel/time/tick-sched.c
@@ -1119,6 +1119,105 @@ void tick_setup_sched_timer(void)
 }
 #endif /* HIGH_RES_TIMERS */
 
+#ifdef CONFIG_TICK_THROTTLING
+/*
+ * An interrupt might have been pending already, when we programmed
+ * the throttler time. Nothing to do here. The device is armed and the
+ * interrupt will fire again. If this is the real wakeup event then
+ * the unblock call will retrigger it.
+ */
+static void tick_throttling_handler(struct clock_event_device *dev)
+{
+}
+
+static int tick_throttling_noop(unsigned long evt,
+				struct clock_event_device *d)
+{
+	return 0;
+}
+
+static struct clock_event_device tick_throttler = {
+	.name		= "throttler",
+	.features	= CLOCK_EVT_FEAT_ONESHOT,
+	.event_handler	= tick_throttling_handler,
+	.set_next_event	= tick_throttling_noop,
+	.mult		= 1,
+	.shift		= 0,
+	.irq		= -1,
+};
+
+/**
+ * tick_nohz_block_tick - Force block the tick to prevent fire
+ * @delay:	Defer the tick for X nano seconds
+ *
+ * This is a special interface for thermal emergencies. Do not use
+ * otherwise!  Make sure to call tick_nohz_block_tick() right after
+ * the delay ends to undo the damage.
+ */
+int tick_nohz_block_tick(u64 delay)
+{
+	struct tick_device *td;
+	unsigned long flags;
+	int ret = -EBUSY;
+	ktime_t until;
+
+	if (!tick_nohz_active)
+		return -EBUSY;
+
+	local_irq_save(flags);
+	td = this_cpu_ptr(&tick_cpu_device);
+
+	/* No way to do that with broadcast */
+	if (td->evtdev->features & CLOCK_EVT_FEAT_C3STOP)
+		goto out;
+
+	/* Yes, I do not trust people! */
+	if (WARN_ON_ONCE(td->evtdev == &tick_throttler))
+		goto out;
+
+	if (delay > td->evtdev->max_delta_ticks) {
+		ret = -EINVAL;
+		goto out;
+	}
+
+	until = ktime_add_ns(ktime_get(), delay);
+	if (!tick_program_event(until, 0)) {
+		td->real_evtdev = td->evtdev;
+		td->evtdev = &tick_throttler;
+		ret = 0;
+	}
+out:
+	local_irq_restore(flags);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(tick_nohz_block_tick);
+
+/**
+ * tick_nohz_force_unblock_tick - Undo the force blocking of the tick
+ *
+ * Pairs with tick_nohz_block_tick(). Can be called unconditionally
+ * even if the tick was not blocked by tick_nohz_block_tick().
+ */
+void tick_nohz_unblock_tick(void)
+{
+	struct tick_device *td;
+	unsigned long flags;
+
+	if (!tick_nohz_active)
+		return;
+
+	local_irq_save(flags);
+	td = this_cpu_ptr(&tick_cpu_device);
+	if (td->evtdev == &tick_throttler) {
+		td->evtdev = td->real_evtdev;
+		/* Force a timer interrupt now */
+		tick_program_event(ktime_get(), 1);
+	}
+	local_irq_restore(flags);
+}
+EXPORT_SYMBOL_GPL(tick_nohz_unblock_tick);
+#endif /* TICK_THROTTLING */
+
 #if defined CONFIG_NO_HZ_COMMON || defined CONFIG_HIGH_RES_TIMERS
 void tick_cancel_sched_timer(int cpu)
 {
Index: tip/kernel/time/tick-sched.h
===================================================================
--- tip.orig/kernel/time/tick-sched.h
+++ tip/kernel/time/tick-sched.h
@@ -9,8 +9,11 @@ enum tick_device_mode {
 };
 
 struct tick_device {
-	struct clock_event_device *evtdev;
-	enum tick_device_mode mode;
+	struct clock_event_device	*evtdev;
+	enum tick_device_mode		mode;
+#ifdef CONFIG_TICK_THROTTLING
+	struct clock_event_device	*real_evtdev;
+#endif
 };
 
 enum tick_nohz_mode {




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1276346

On Fri, 20 Nov 2015 11:58:12 +0100 (CET)
Thomas Gleixner <tglx@linutronix.de> wrote:

> 	 if (machine_on_fire) {
Just to add data to show this is not just for emergency. I have an
broadwell laptop, here is the test I did.
- clamp cpu freq to 900MHz (close to max efficiency)
- run gpu and cpu load (cut-the-rop, glxgears)
- turn fans off

run tmon (tools/thermal/tmon) to show temperatures and thermal trip
points. (sorry about the long lines, quite  a few thermal sensors)
Also run turbostat to show CPU idle etc.

Observations:
without idle injection:
------------------------------------------------------------------
- package temp rise to 66C crossing the second active trip points
	(2nd fan speed should kick in if not disabled)
- package power 9.47w
- cpu c0 ~90%, 0% core c7
------------------------------------------------------------------
- with idle injection 20%
- cpu c0 ~67%, ~13% core c7, ~7% package c-states
- package power 4.53w
- package temp 52C

glxgears maintains the same frame rate. didnt measure cut-the-rope
but still plays.

This is a large 14 inch laptop with much better cooling than a fanless
tablet/convertible. So hitting thermal constraints can happen in _NORMAL_
condition (even at 900MHz), not just on fire case.

Sync up idle can save energy efficiency and i think scheduler is a better
place to solve that problem, perhaps with PM QoS constraint will have less
perceived intrusive behavior.

Thanks,

Jacob
 

│Trip Points:                   AAAAC       C                       AAPHCPP     APHCPP      PHCPP       AAPHCPP     AAAAPHCPP   APHCPP      AAAAPHC     PP                                                                                                    │
└─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
┌──────────────────────────────────────────────────────────────────────────────────────────────────────────── COOLING DEVICES ────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ID  Cooling Dev   Cur    Max   Thermal Zone Binding                                                                                                                                                                                                          │
│00         TFN1     4     11   │││││││││││ │││││││││││ │││││││││││ │││││││││││ │││││││││││ │││││││││││ │││││││││││ │││││││││││ │││││││││││ │││││││││││ ││││││││││││                                                                                          │
│01          Fan     0      1   │││*│││││││ │││││││││││ │││││││││││ │││││││││││ │││││││││││ │││││││││││ │││││││││││ │││││││││││ │││││││││││ │││││││││││ ││││││││││││                                                                                          │
│02          Fan     0      1   ││*││││││││ │││││││││││ │││││││││││ │││││││││││ │││││││││││ │││││││││││ │││││││││││ │││││││││││ │││││││││││ │││││││││││ ││││││││││││                                                                                          │
│03          Fan     0      1   │*│││││││││ │││││││││││ │││││││││││ │││││││││││ │││││││││││ │││││││││││ │││││││││││ │││││││││││ │││││││││││ │││││││││││ ││││││││││││                                                                                          │
│04          Fan     0      1   *││││││││││ │││││││││││ │││││││││││ │││││││││││ │││││││││││ │││││││││││ │││││││││││ │││││││││││ │││││││││││ │││││││││││ ││││││││││││                                                                                          │
│05         CHRG     4      4   │││││││││││ │││││││││││ │││││││││││ │││││││││││ │││││││││││ │││││││││││ │││││││││││ │││││││││││ │││││││││││ │││││││││││ ││││││││││││                                                                                          │
│06 intel_powerc    -1     50   │││││││││││ │││││││││││ │││││││││││ │││││││││││ │││││││││││ │││││││││││ │││││││││││ │││││││││││ │││││││││││ │││││││││││ ││││││││││││                                                                                          │
└─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│                         10        20        30        40        50        60        70        80        90        100       110       120                                                                                                                   │
│acpitz 0:[ 66][→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→A55→→→→→→→A65       A75       A85                       C111          ]                                                                                                                │
│pch_wi 1:[ 59][→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→                                                       C115      ]                                                                                                                │
│INT340 2:[ 20][→→→→→→→→→→→→→→→→→→→→→                                                                                                        ]                                                                                                                │
│  SEN1 3:[ 47][P0→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→          A58  A63     P71                          H100103                  ]                                                                                                                │
│  SEN2 4:[ 51][P0→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→           A63     P71                          H100103                  ]                                                                                                                │
│  SEN3 5:[ 46][P0→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→                        P71                          H100103                  ]                                                                                                                │
│  SEN4 6:[ 45][P0→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→            A58  A63     P71                          H100103                  ]                                                                                                                │
│  SEN6 7:[ 46][P0→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→ A48  A53  A58  A63     P71                          H100103                  ]                                                                                                                │
│  SEN7 8:[ 27][P0→→→→→→→→→→→→→→→→→→→→→→→→→→                                   A63     P71                          H100103                  ]                                                                                                                │
│  B0D4 9:[ 66][→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→A55→→→→→→→A65       A75       A85              P102045                ]                                                                                                                │
│x86_pk10:[ 66][P0→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→→                                                          ]                                                                                                                │
└─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
turbostat without idle injection
      1       3     776   86.37     898    2295       0   11.90
    Core     CPU Avg_MHz   %Busy Bzy_MHz TSC_MHz     SMI  CPU%c1  CPU%c3  CPU%c6  CPU%c7 CoreTmp  PkgTmp Pkg%pc2 Pkg%pc3 Pkg%pc6 Pkg%pc7 Pkg%pc8 Pkg%pc9 Pk%pc10 PkgWatt CorWatt GFXWatt
       -       -     801   89.16     898    2295       0    9.77    0.55    0.07    0.44      66      70    0.00    0.00    0.00    0.00    0.00    0.00    0.00    9.47    4.31    1.17
       0       0     801   89.26     898    2294       0    9.76    0.57    0.07    0.34      64      70    0.00    0.00    0.00    0.00    0.00    0.00    0.00    9.47    4.31    1.17
       0       2     803   89.43     898    2294       0    9.58
       1       1     810   90.27     898    2295       0    8.59    0.52    0.07    0.55      66
       1       3     787   87.69     898    2295       0   11.17

turbostat with 20% idle injection
    Core     CPU Avg_MHz   %Busy Bzy_MHz TSC_MHz     SMI  CPU%c1  CPU%c3  CPU%c6  CPU%c7 CoreTmp  PkgTmp Pkg%pc2 Pkg%pc3 Pkg%pc6 Pkg%pc7 Pkg%pc8 Pkg%pc9 Pk%pc10 PkgWatt CorWatt GFXWatt
       -       -     601   66.92     898    2295       0   13.48    4.65    1.09   13.86      52      52    3.50    0.60    0.46    2.30    0.00    0.00    0.00    4.53    1.99    0.17
       0       0     605   67.36     898    2294       0   12.75    5.95    1.51   12.42      51      52    3.50    0.60    0.46    2.30    0.00    0.00    0.00    4.53    1.99    0.17
       0       2     583   64.94     898    2295       0   15.18
       1       1     605   67.37     898    2295       0   13.31    3.34    0.67   15.30      52
       1       3     611   68.02     898    2295       0   12.66

~                                                                                                                                                                                                                                                              
~                                                                                                                                                                                                                                                              
~                                                                                                                                                             

> 	        defer_timer_interrupt(5ms);
> 		end = now + 5ms:
> 	    	while (now < end)
> 		      mwait();
>          }

[Jacob Pan]
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1275686

On Thu, 19 Nov 2015 17:24:07 +0000
Morten Rasmussen <morten.rasmussen@arm.com> wrote:

> I could see this technique being useful within the SoC as well.
> Synchronized idle injection on all cpus in a cluster would allow us to
> reach cluster idle states where resources shared within the cluster
> can be gated or powered off as well. But yes, shutting down
> everything is more efficient if you are en serious trouble.
> 
> I was hoping this could be a good alternative to hotplugging cpus out
> for thermal management in non-critical situations, but it isn't that
> appealing if you have to throttle all the cpus. I would consider it an
> emergency-only mechanism (as in emergency brake) that isn't really
> suitable for normal thermal management. In which case: Does this sort
> of mechanism belong in the scheduler code?
I would think this is not an emergency-only mechanism. I know shutting
down all CPUs at the same time sounds bad but here are advantage of
having this in the scheduler in that we can still have certain QoS.
e.g. we yeild softirq, RT. etc. There are other workload info readily
available in the scheduler to better use this knob. e.g. sync with
other input timers such as media.

For normal thermal conditions, Skylake for example, the max efficient
frequency is ~900MHz. If thermal restriction happens (e.g. you want to
do fanless), would you like to lose energy efficiency by further
lowering frequency to 500Mhz? or do idle injection and take 5ms latency
for normal tasks? Idle injection gives you near linear
performance-power scaling.

Thanks,

Jacob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web