Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1683892 > unrolled thread
| Started by | Aubrey Li <aubrey.li@intel.com> |
|---|---|
| First post | 2017-07-10 03:50 +0200 |
| Last post | 2017-07-11 11:10 +0200 |
| Articles | 20 on this page of 109 — 11 participants |
Back to article view | Back to linux.kernel
[RFC PATCH v1 00/11] Create fast idle path for short idle periods Aubrey Li <aubrey.li@intel.com> - 2017-07-10 03:50 +0200
[RFC PATCH v1 04/11] sched/idle: make the fast idle path for short idle periods Aubrey Li <aubrey.li@intel.com> - 2017-07-10 03:50 +0200
Re: [RFC PATCH v1 04/11] sched/idle: make the fast idle path for short idle periods "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-07-11 15:00 +0200
Re: [RFC PATCH v1 04/11] sched/idle: make the fast idle path for short idle periods Frederic Weisbecker <fweisbec@gmail.com> - 2017-07-11 18:40 +0200
Re: [RFC PATCH v1 04/11] sched/idle: make the fast idle path for short idle periods "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-07-11 20:20 +0200
Re: [RFC PATCH v1 04/11] sched/idle: make the fast idle path for short idle periods "Li, Aubrey" <aubrey.li@linux.intel.com> - 2017-07-12 05:30 +0200
Re: [RFC PATCH v1 04/11] sched/idle: make the fast idle path for short idle periods "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-07-12 07:10 +0200
Re: [RFC PATCH v1 04/11] sched/idle: make the fast idle path for short idle periods "Li, Aubrey" <aubrey.li@linux.intel.com> - 2017-07-12 07:30 +0200
Re: [RFC PATCH v1 04/11] sched/idle: make the fast idle path for short idle periods Peter Zijlstra <peterz@infradead.org> - 2017-07-12 14:30 +0200
[RFC PATCH v1 05/11] cpuidle: update idle statistics before cpuidle governor Aubrey Li <aubrey.li@intel.com> - 2017-07-10 03:50 +0200
[RFC PATCH v1 08/11] cpuidle: menu: remove reduplicative implementation Aubrey Li <aubrey.li@intel.com> - 2017-07-10 04:00 +0200
[RFC PATCH v1 07/11] cpuidle: make idle residency update more generic Aubrey Li <aubrey.li@intel.com> - 2017-07-10 04:00 +0200
[RFC PATCH v1 03/11] cpuidle: introduce cpuidle governor for idle prediction Aubrey Li <aubrey.li@intel.com> - 2017-07-10 04:00 +0200
Re: [RFC PATCH v1 03/11] cpuidle: introduce cpuidle governor for idle prediction Peter Zijlstra <peterz@infradead.org> - 2017-07-12 14:20 +0200
[RFC PATCH v1 09/11] cpuidle: menu: feed cpuidle prediction to menu governor Aubrey Li <aubrey.li@intel.com> - 2017-07-10 04:00 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Peter Zijlstra <peterz@infradead.org> - 2017-07-10 10:50 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Wanpeng Li <kernellwp@gmail.com> - 2017-07-10 11:40 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods "Li, Aubrey" <aubrey.li@linux.intel.com> - 2017-07-10 16:00 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Andi Kleen <ak@linux.intel.com> - 2017-07-10 16:50 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Peter Zijlstra <peterz@infradead.org> - 2017-07-10 18:50 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Andi Kleen <ak@linux.intel.com> - 2017-07-10 19:30 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods "Li, Aubrey" <aubrey.li@linux.intel.com> - 2017-07-11 06:50 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Peter Zijlstra <peterz@infradead.org> - 2017-07-11 11:50 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Frederic Weisbecker <fweisbec@gmail.com> - 2017-07-11 18:10 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Peter Zijlstra <peterz@infradead.org> - 2017-07-11 18:40 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-07-11 20:10 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Peter Zijlstra <peterz@infradead.org> - 2017-07-12 14:00 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-07-12 18:00 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Peter Zijlstra <peterz@infradead.org> - 2017-07-12 19:50 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-07-12 21:00 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-07-12 21:10 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Frederic Weisbecker <fweisbec@gmail.com> - 2017-07-19 15:50 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-07-19 17:00 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Peter Zijlstra <peterz@infradead.org> - 2017-07-12 14:30 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-07-12 18:00 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Peter Zijlstra <peterz@infradead.org> - 2017-07-12 19:20 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Peter Zijlstra <peterz@infradead.org> - 2017-07-12 20:00 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-07-12 21:00 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-07-12 20:50 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Peter Zijlstra <peterz@infradead.org> - 2017-07-13 10:40 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods "Li, Aubrey" <aubrey.li@linux.intel.com> - 2017-07-12 06:20 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Peter Zijlstra <peterz@infradead.org> - 2017-07-12 10:40 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Andi Kleen <ak@linux.intel.com> - 2017-07-12 23:40 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Peter Zijlstra <peterz@infradead.org> - 2017-07-13 10:40 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods "Li, Aubrey" <aubrey.li@linux.intel.com> - 2017-07-13 16:50 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Peter Zijlstra <peterz@infradead.org> - 2017-07-13 17:00 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods "Li, Aubrey" <aubrey.li@linux.intel.com> - 2017-07-13 17:20 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Peter Zijlstra <peterz@infradead.org> - 2017-07-13 20:30 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods "Li, Aubrey" <aubrey.li@linux.intel.com> - 2017-07-14 06:00 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Peter Zijlstra <peterz@infradead.org> - 2017-07-14 17:40 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Peter Zijlstra <peterz@infradead.org> - 2017-07-14 18:00 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Andi Kleen <ak@linux.intel.com> - 2017-07-14 18:10 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Peter Zijlstra <peterz@infradead.org> - 2017-07-17 11:30 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods "Li, Aubrey" <aubrey.li@linux.intel.com> - 2017-07-17 15:50 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Andi Kleen <ak@linux.intel.com> - 2017-07-14 18:00 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Peter Zijlstra <peterz@infradead.org> - 2017-07-14 18:10 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Andi Kleen <ak@linux.intel.com> - 2017-07-14 18:30 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Peter Zijlstra <peterz@infradead.org> - 2017-07-17 21:30 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Arjan van de Ven <arjan@linux.intel.com> - 2017-07-17 21:30 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Thomas Gleixner <tglx@linutronix.de> - 2017-07-17 21:50 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Arjan van de Ven <arjan@linux.intel.com> - 2017-07-17 22:00 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Thomas Gleixner <tglx@linutronix.de> - 2017-07-17 22:10 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Arjan van de Ven <arjan@linux.intel.com> - 2017-07-17 21:50 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Thomas Gleixner <tglx@linutronix.de> - 2017-07-17 22:00 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Arjan van de Ven <arjan@linux.intel.com> - 2017-07-17 22:00 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods "Li, Aubrey" <aubrey.li@linux.intel.com> - 2017-07-18 05:30 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Peter Zijlstra <peterz@infradead.org> - 2017-07-18 21:00 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods "Li, Aubrey" <aubrey.li@linux.intel.com> - 2017-07-18 05:20 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Andi Kleen <ak@linux.intel.com> - 2017-07-18 06:50 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Thomas Gleixner <tglx@linutronix.de> - 2017-07-18 08:50 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Andi Kleen <ak@linux.intel.com> - 2017-07-18 09:00 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Thomas Gleixner <tglx@linutronix.de> - 2017-07-18 09:20 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods "Li, Aubrey" <aubrey.li@linux.intel.com> - 2017-07-19 08:20 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Thomas Gleixner <tglx@linutronix.de> - 2017-07-19 10:00 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods "Li, Aubrey" <aubrey.li@linux.intel.com> - 2017-07-20 04:00 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Thomas Gleixner <tglx@linutronix.de> - 2017-07-20 10:20 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Arjan van de Ven <arjan@linux.intel.com> - 2017-07-20 15:50 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Thomas Gleixner <tglx@linutronix.de> - 2017-07-18 09:30 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods "Li, Aubrey" <aubrey.li@linux.intel.com> - 2017-07-18 09:00 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-07-18 17:30 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Arjan van de Ven <arjan@linux.intel.com> - 2017-07-18 17:30 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Arjan van de Ven <arjan@linux.intel.com> - 2017-07-18 18:40 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Peter Zijlstra <peterz@infradead.org> - 2017-07-18 19:10 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Peter Zijlstra <peterz@infradead.org> - 2017-07-18 18:40 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods "Li, Aubrey" <aubrey.li@linux.intel.com> - 2017-07-19 07:50 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-07-19 16:50 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Christopher Lameter <cl@linux.com> - 2017-07-19 17:10 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-07-19 19:00 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods "Li, Aubrey" <aubrey.li@linux.intel.com> - 2017-07-20 03:50 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-07-20 15:00 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Arjan van de Ven <arjan@linux.intel.com> - 2017-07-20 15:50 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Peter Zijlstra <peterz@infradead.org> - 2017-07-20 16:30 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-07-20 18:10 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Peter Zijlstra <peterz@infradead.org> - 2017-07-18 18:50 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Peter Zijlstra <peterz@infradead.org> - 2017-07-18 15:30 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Peter Zijlstra <peterz@infradead.org> - 2017-07-19 15:50 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Arjan van de Ven <arjan@linux.intel.com> - 2017-07-14 18:00 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-07-13 17:30 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods "Li, Aubrey" <aubrey.li@linux.intel.com> - 2017-07-14 05:50 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-07-14 06:10 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods "Li, Aubrey" <aubrey.li@linux.intel.com> - 2017-07-17 15:30 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Peter Zijlstra <peterz@infradead.org> - 2017-07-17 16:00 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods "Li, Aubrey" <aubrey.li@linux.intel.com> - 2017-07-17 16:10 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Peter Zijlstra <peterz@infradead.org> - 2017-07-12 14:20 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Christoph Lameter <cl@linux.com> - 2017-07-11 20:00 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods "Li, Aubrey" <aubrey.li@linux.intel.com> - 2017-07-12 04:10 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods "Li, Aubrey" <aubrey.li@linux.intel.com> - 2017-07-12 04:40 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Peter Zijlstra <peterz@infradead.org> - 2017-07-12 20:20 +0200
Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods Peter Zijlstra <peterz@infradead.org> - 2017-07-11 11:10 +0200
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
| From | Arjan van de Ven <arjan@linux.intel.com> |
|---|---|
| Date | 2017-07-17 22:00 +0200 |
| Message-ID | <u4kls-SQ-27@gated-at.bofh.it> |
| In reply to | #1689402 |
On 7/17/2017 12:46 PM, Thomas Gleixner wrote: > On Mon, 17 Jul 2017, Arjan van de Ven wrote: >> On 7/17/2017 12:23 PM, Peter Zijlstra wrote: >>> Now I think the problem is that the current predictor goes for an >>> average idle duration. This means that we, on average, get it wrong 50% >>> of the time. For performance that's bad. >> >> that's not really what it does; it looks at next tick >> and then discounts that based on history; >> (with different discounts for different order of magnitude) > > next tick is the worst thing to look at for interrupt heavy workloads as well it was better than what was there before (without discount and without detecting repeated patterns) > the next tick (as computed by the nohz code) can be far away, while the I/O > interrupts come in at a high frequency. > > That's where Daniel Lezcanos work of predicting interrupts comes in and > that's the right solution to the problem. The core infrastructure has been > merged, just the idle/cpufreq users are not there yet. All you need to do > is to select CONFIG_IRQ_TIMINGS and use the statistics generated there. > yes ;-) also note that the predictor does not need to perfect, on most systems C states are an order of magnitude apart in terms of power/performance/latency so if you get the general order of magnitude right the predictor is doing its job. (this is not universally true, but physics of power gating/etc tend to drive to this conclusion; the cost of implementing an extra state very close to another state means that the HW folks are unlikely to do the less power saving state of the two to save their cost and testing effort)
[toc] | [prev] | [next] | [standalone]
| From | Thomas Gleixner <tglx@linutronix.de> |
|---|---|
| Date | 2017-07-17 22:10 +0200 |
| Subject | Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods |
| Message-ID | <u4kv7-1bl-11@gated-at.bofh.it> |
| In reply to | #1689421 |
On Mon, 17 Jul 2017, Arjan van de Ven wrote: > On 7/17/2017 12:46 PM, Thomas Gleixner wrote: > > That's where Daniel Lezcanos work of predicting interrupts comes in and > > that's the right solution to the problem. The core infrastructure has been > > merged, just the idle/cpufreq users are not there yet. All you need to do > > is to select CONFIG_IRQ_TIMINGS and use the statistics generated there. > > > yes ;-) :) > also note that the predictor does not need to perfect, on most systems C > states are an order of magnitude apart in terms of > power/performance/latency so if you get the general order of magnitude > right the predictor is doing its job. So it would be interesting just to enable the irq timings stuff and compare the outcome as a first step. That should be reasonably simple to implement and would give us also some information of how that code behaves on larger systems. Thanks, tglx
[toc] | [prev] | [next] | [standalone]
| From | Arjan van de Ven <arjan@linux.intel.com> |
|---|---|
| Date | 2017-07-17 21:50 +0200 |
| Message-ID | <u4kbN-Pt-51@gated-at.bofh.it> |
| In reply to | #1689384 |
On 7/17/2017 12:23 PM, Peter Zijlstra wrote: > Of course, this all assumes a Gaussian distribution to begin with, if we > get bimodal (or worse) distributions we can still get it wrong. To fix > that, we'd need to do something better than what we currently have. > fwiw some time ago I made a chart for predicted vs actual so you can sort of judge the distribution of things visually http://git.fenrus.org/tmp/linux2.png
[toc] | [prev] | [next] | [standalone]
| From | Thomas Gleixner <tglx@linutronix.de> |
|---|---|
| Date | 2017-07-17 22:00 +0200 |
| Subject | Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods |
| Message-ID | <u4klr-SQ-5@gated-at.bofh.it> |
| In reply to | #1689411 |
On Mon, 17 Jul 2017, Arjan van de Ven wrote: > On 7/17/2017 12:23 PM, Peter Zijlstra wrote: > > Of course, this all assumes a Gaussian distribution to begin with, if we > > get bimodal (or worse) distributions we can still get it wrong. To fix > > that, we'd need to do something better than what we currently have. > > > > fwiw some time ago I made a chart for predicted vs actual so you can sort > of judge the distribution of things visually Predicted by what? Thanks, tglx
[toc] | [prev] | [next] | [standalone]
| From | Arjan van de Ven <arjan@linux.intel.com> |
|---|---|
| Date | 2017-07-17 22:00 +0200 |
| Message-ID | <u4kls-SQ-31@gated-at.bofh.it> |
| In reply to | #1689414 |
On 7/17/2017 12:53 PM, Thomas Gleixner wrote: > On Mon, 17 Jul 2017, Arjan van de Ven wrote: >> On 7/17/2017 12:23 PM, Peter Zijlstra wrote: >>> Of course, this all assumes a Gaussian distribution to begin with, if we >>> get bimodal (or worse) distributions we can still get it wrong. To fix >>> that, we'd need to do something better than what we currently have. >>> >> >> fwiw some time ago I made a chart for predicted vs actual so you can sort >> of judge the distribution of things visually > > Predicted by what? this chart was with the current linux predictor http://git.fenrus.org/tmp/timer.png is what you get if you JUST use the next timer ;-) (which way back linux was doing)
[toc] | [prev] | [next] | [standalone]
| From | "Li, Aubrey" <aubrey.li@linux.intel.com> |
|---|---|
| Date | 2017-07-18 05:30 +0200 |
| Message-ID | <u4rmV-5vl-15@gated-at.bofh.it> |
| In reply to | #1689411 |
On 2017/7/18 3:48, Arjan van de Ven wrote: > On 7/17/2017 12:23 PM, Peter Zijlstra wrote: >> Of course, this all assumes a Gaussian distribution to begin with, if we >> get bimodal (or worse) distributions we can still get it wrong. To fix >> that, we'd need to do something better than what we currently have. >> > > fwiw some time ago I made a chart for predicted vs actual so you can sort > of judge the distribution of things visually > > http://git.fenrus.org/tmp/linux2.png > > This does not look like a Gaussian, does it? I mean abs(expected - actual). Thanks, -Aubrey
[toc] | [prev] | [next] | [standalone]
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Date | 2017-07-18 21:00 +0200 |
| Message-ID | <u4FSW-61V-23@gated-at.bofh.it> |
| In reply to | #1689411 |
On Mon, Jul 17, 2017 at 12:48:38PM -0700, Arjan van de Ven wrote: > On 7/17/2017 12:23 PM, Peter Zijlstra wrote: > > Of course, this all assumes a Gaussian distribution to begin with, if we > > get bimodal (or worse) distributions we can still get it wrong. To fix > > that, we'd need to do something better than what we currently have. > > > > fwiw some time ago I made a chart for predicted vs actual so you can sort > of judge the distribution of things visually > > http://git.fenrus.org/tmp/linux2.png That shows we get it wrong a lot of times (about 50%, as per the average) and moving the line has benefit. Since for performance you really don't want to pick the deeper idle state, so you want to bias your pick towards a shallower state. Using the CDF approach you can quantify by how much you want it moved.
[toc] | [prev] | [next] | [standalone]
| From | "Li, Aubrey" <aubrey.li@linux.intel.com> |
|---|---|
| Date | 2017-07-18 05:20 +0200 |
| Message-ID | <u4rdf-5rV-1@gated-at.bofh.it> |
| In reply to | #1689384 |
On 2017/7/18 3:23, Peter Zijlstra wrote: > On Fri, Jul 14, 2017 at 09:26:19AM -0700, Andi Kleen wrote: >>> And as said; Daniel has been working on a better predictor -- now he's >>> probably not used it on the network workload you're looking at, so that >>> might be something to consider. >> >> Deriving a better idle predictor is a bit orthogonal to fast idle. > > No. If you want a different C state selected we need to fix the current > C state selector. We're not going to tinker. > > And the predictor is probably the most fundamental part of the whole C > state selection logic. > > Now I think the problem is that the current predictor goes for an > average idle duration. This means that we, on average, get it wrong 50% > of the time. For performance that's bad. > > If you want to improve the worst case, we need to consider a cumulative > distribution function, and staying with the Gaussian assumption already > present, that would mean using: > > 1 x - mu > CDF(x) = - [ 1 + erf(-------------) ] > 2 sigma sqrt(2) > > Where, per the normal convention mu is the average and sigma^2 the > variance. See also: > > https://en.wikipedia.org/wiki/Normal_distribution > > We then solve CDF(x) = n% to find the x for which we get it wrong n% of > the time (IIRC something like: 'mu - 2sigma' ends up being 5% or so). > > This conceptually gets us better exit latency for the cases where we got > it wrong before, and practically pushes down the estimate which gets us > C1 longer. > > Of course, this all assumes a Gaussian distribution to begin with, if we > get bimodal (or worse) distributions we can still get it wrong. To fix > that, we'd need to do something better than what we currently have. > Maybe you are talking about applying some machine learning algorithm online to fit a multivariate normal distribution, :) Well, back to the problem, when the scheduler picks up idle thread, it does not look at the history, nor make the prediction. So it's possible it has to switch back a task ASAP when it's going into idle(very common under some workloads). That is, (idle_entry + idle_exit) > idle. If the system has multiple hardware idle states, then: (idle_entry + idle_exit + HW_entry + HW_exit) > HW_sleep So we eventually want the idle path lighter than what we currently have. A complex predictor may have high accuracy, but the cost could be high as well. We need a tradeoff here IMHO. I'll check Daniel's work to understand how/if it's better than menu governor. Thanks, -Aubrey
[toc] | [prev] | [next] | [standalone]
| From | Andi Kleen <ak@linux.intel.com> |
|---|---|
| Date | 2017-07-18 06:50 +0200 |
| Message-ID | <u4sCl-6f0-3@gated-at.bofh.it> |
| In reply to | #1689628 |
> We need a tradeoff here IMHO. I'll check Daniel's work to understand how/if > it's better than menu governor. I still would like to see how the fast path without the C1 heuristic works. Fast pathing is a different concept from a better predictor. IMHO we need both, but the first is likely lower hanging fruit. -Andi
[toc] | [prev] | [next] | [standalone]
| From | Thomas Gleixner <tglx@linutronix.de> |
|---|---|
| Date | 2017-07-18 08:50 +0200 |
| Subject | Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods |
| Message-ID | <u4uut-7ol-11@gated-at.bofh.it> |
| In reply to | #1689690 |
On Mon, 17 Jul 2017, Andi Kleen wrote: > > We need a tradeoff here IMHO. I'll check Daniel's work to understand how/if > > it's better than menu governor. > > I still would like to see how the fast path without the C1 heuristic works. > > Fast pathing is a different concept from a better predictor. IMHO we need > both, but the first is likely lower hanging fruit. Hacking something on the side is always the lower hanging fruit as it avoids solving the hard problems. As Peter said already, that's not going to happen unless there is a real technical reason why the general path cannot be fixed. So far there is no proof for that. Thanks, tglx
[toc] | [prev] | [next] | [standalone]
| From | Andi Kleen <ak@linux.intel.com> |
|---|---|
| Date | 2017-07-18 09:00 +0200 |
| Message-ID | <u4uEa-7rF-13@gated-at.bofh.it> |
| In reply to | #1689778 |
On Tue, Jul 18, 2017 at 08:43:53AM +0200, Thomas Gleixner wrote: > On Mon, 17 Jul 2017, Andi Kleen wrote: > > > > We need a tradeoff here IMHO. I'll check Daniel's work to understand how/if > > > it's better than menu governor. > > > > I still would like to see how the fast path without the C1 heuristic works. > > > > Fast pathing is a different concept from a better predictor. IMHO we need > > both, but the first is likely lower hanging fruit. > > Hacking something on the side is always the lower hanging fruit as it > avoids solving the hard problems. As Peter said already, that's not going > to happen unless there is a real technical reason why the general path > cannot be fixed. So far there is no proof for that. You didn't look at Aubrey's data? There are some unavoidable slow operations in the current path -- e.g. reprograming the timer for NOHZ. But we don't need that for really short idle periods, because as you pointed out they never get woken up by the tick. Similar for other things like RCU. I don't see how you can avoid that other than without a fast path mechanism. Clearly these operations are eventually needed, just not all the time for short sleeps. Now in theory you could have lots of little fast paths in all the individual operations that check this individually, but I don't see how that is better than a single simple fast path. -Andi
[toc] | [prev] | [next] | [standalone]
| From | Thomas Gleixner <tglx@linutronix.de> |
|---|---|
| Date | 2017-07-18 09:20 +0200 |
| Subject | Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods |
| Message-ID | <u4uXw-7P3-13@gated-at.bofh.it> |
| In reply to | #1689787 |
On Mon, 17 Jul 2017, Andi Kleen wrote: > On Tue, Jul 18, 2017 at 08:43:53AM +0200, Thomas Gleixner wrote: > > On Mon, 17 Jul 2017, Andi Kleen wrote: > > > > > > We need a tradeoff here IMHO. I'll check Daniel's work to understand how/if > > > > it's better than menu governor. > > > > > > I still would like to see how the fast path without the C1 heuristic works. > > > > > > Fast pathing is a different concept from a better predictor. IMHO we need > > > both, but the first is likely lower hanging fruit. > > > > Hacking something on the side is always the lower hanging fruit as it > > avoids solving the hard problems. As Peter said already, that's not going > > to happen unless there is a real technical reason why the general path > > cannot be fixed. So far there is no proof for that. > > You didn't look at Aubrey's data? > > There are some unavoidable slow operations in the current path -- e.g. > reprograming the timer for NOHZ. But we don't need that for really > short idle periods, because as you pointed out they never get woken > up by the tick. > > Similar for other things like RCU. > > I don't see how you can avoid that other than without a fast path mechanism. You can very well avoid it by taking the irq timings or whatever other information into account for the NOHZ decision. Thanks, tglx
[toc] | [prev] | [next] | [standalone]
| From | "Li, Aubrey" <aubrey.li@linux.intel.com> |
|---|---|
| Date | 2017-07-19 08:20 +0200 |
| Message-ID | <u4Qv0-4B3-15@gated-at.bofh.it> |
| In reply to | #1689799 |
On 2017/7/18 15:19, Thomas Gleixner wrote: > On Mon, 17 Jul 2017, Andi Kleen wrote: >> On Tue, Jul 18, 2017 at 08:43:53AM +0200, Thomas Gleixner wrote: >>> On Mon, 17 Jul 2017, Andi Kleen wrote: >>> >>>>> We need a tradeoff here IMHO. I'll check Daniel's work to understand how/if >>>>> it's better than menu governor. >>>> >>>> I still would like to see how the fast path without the C1 heuristic works. >>>> >>>> Fast pathing is a different concept from a better predictor. IMHO we need >>>> both, but the first is likely lower hanging fruit. >>> >>> Hacking something on the side is always the lower hanging fruit as it >>> avoids solving the hard problems. As Peter said already, that's not going >>> to happen unless there is a real technical reason why the general path >>> cannot be fixed. So far there is no proof for that. >> >> You didn't look at Aubrey's data? >> >> There are some unavoidable slow operations in the current path -- e.g. >> reprograming the timer for NOHZ. But we don't need that for really >> short idle periods, because as you pointed out they never get woken >> up by the tick. >> >> Similar for other things like RCU. >> >> I don't see how you can avoid that other than without a fast path mechanism. > > You can very well avoid it by taking the irq timings or whatever other > information into account for the NOHZ decision. > If I read the source correctly, irq timing statistics computation happens at idle time. Sadly, this is what Andi Kleen worried about. People keep putting more and more slow stuff in idle path, not realizing it could be a critical path. /* * The computation happens at idle time. When the CPU is not idle, the * interrupts' timestamps are stored in the circular buffer, when the * CPU goes idle and this routine is called, all the buffer's values * are injected in the statistical model continuing to extend the * statistics from the previous busy-idle cycle. */ Thanks, -Aubrey
[toc] | [prev] | [next] | [standalone]
| From | Thomas Gleixner <tglx@linutronix.de> |
|---|---|
| Date | 2017-07-19 10:00 +0200 |
| Subject | Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods |
| Message-ID | <u4S3M-5v4-13@gated-at.bofh.it> |
| In reply to | #1691003 |
On Wed, 19 Jul 2017, Li, Aubrey wrote: > On 2017/7/18 15:19, Thomas Gleixner wrote: > > You can very well avoid it by taking the irq timings or whatever other > > information into account for the NOHZ decision. > > > If I read the source correctly, irq timing statistics computation happens at > idle time. Sadly, this is what Andi Kleen worried about. People keep putting > more and more slow stuff in idle path, not realizing it could be a critical path. Can you please stop this right here? We all realize that there is an issue, we are not as stupid as you might think. But we disagree that the proper solution is to add an ad hoc hack which shortcuts stuff and creates a maintenance problem in the long run. Just dismissing a proposal based on 'oh this adds more code to the idle path' and then yelling 'you all do not get it' is not going to solve this in any way. You simply refuse to look at the big picture and you are just not willing to analyze the involved bits and pieces and find a solution which allows to serve both the NOHZ power saving and the interrupt driven workloads best. All you are doing is providing data about the status quo, and then deferring from that, that you need an extra magic code path. That information is just a inventory of the current behaviour and the current behaviour is caused by the current implementation. There is nothing set in stone with that implementation and it can be changed. But you are just in refusal mode and instead of sitting down and doing the hard work, you accuse other people that they are not realizing the problem and insist on your sloppy hackery. That's simply not the way it works. Thanks, tglx
[toc] | [prev] | [next] | [standalone]
| From | "Li, Aubrey" <aubrey.li@linux.intel.com> |
|---|---|
| Date | 2017-07-20 04:00 +0200 |
| Message-ID | <u58UW-gG-17@gated-at.bofh.it> |
| In reply to | #1691082 |
On 2017/7/19 15:55, Thomas Gleixner wrote: > On Wed, 19 Jul 2017, Li, Aubrey wrote: >> On 2017/7/18 15:19, Thomas Gleixner wrote: >>> You can very well avoid it by taking the irq timings or whatever other >>> information into account for the NOHZ decision. >>> >> If I read the source correctly, irq timing statistics computation happens at >> idle time. Sadly, this is what Andi Kleen worried about. People keep putting >> more and more slow stuff in idle path, not realizing it could be a critical path. > > Can you please stop this right here? We all realize that there is an issue, > we are not as stupid as you might think. > > But we disagree that the proper solution is to add an ad hoc hack which > shortcuts stuff and creates a maintenance problem in the long run. > > Just dismissing a proposal based on 'oh this adds more code to the idle > path' and then yelling 'you all do not get it' is not going to solve this > in any way. > > You simply refuse to look at the big picture and you are just not willing > to analyze the involved bits and pieces and find a solution which allows to > serve both the NOHZ power saving and the interrupt driven workloads best. > > All you are doing is providing data about the status quo, and then > deferring from that, that you need an extra magic code path. That > information is just a inventory of the current behaviour and the current > behaviour is caused by the current implementation. There is nothing set in > stone with that implementation and it can be changed. > > But you are just in refusal mode and instead of sitting down and doing the > hard work, you accuse other people that they are not realizing the problem > and insist on your sloppy hackery. That's simply not the way it works. Don't get me wrong, even if a fast path is acceptable, we still need to figure out if the coming idle is short and when to switch. I'm just worried about if irq timings is not an ideal statistics, we have to skip it too. Let me a little time to digest the details of irq timings and obtain some data to see if it's suitable for my case. Thanks, -Aubrey
[toc] | [prev] | [next] | [standalone]
| From | Thomas Gleixner <tglx@linutronix.de> |
|---|---|
| Date | 2017-07-20 10:20 +0200 |
| Subject | Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods |
| Message-ID | <u5eQG-4Bm-17@gated-at.bofh.it> |
| In reply to | #1692340 |
On Thu, 20 Jul 2017, Li, Aubrey wrote:
> Don't get me wrong, even if a fast path is acceptable, we still need to
> figure out if the coming idle is short and when to switch. I'm just worried
> about if irq timings is not an ideal statistics, we have to skip it too.
There is no ideal solution ever.
Lets sit back and look at that from the big picture first before dismissing
a particular item upfront.
The current NOHZ implementation does:
predict = nohz_predict(timers, rcu, arch, irqwork);
if ((predict - now) > X)
stop_tick()
The C-State machinery does something like:
predict = cstate_predict(next_timer, scheduler);
cstate = cstate_select(predict);
That disconnect is part of the problem. What we really want is:
predict = idle_predict(timers, rcu, arch, irqwork, scheduler, irq timings);
and use that prediction for both the NOHZ and the C-State decision
function. That's the first thing which needs to be addressed.
Once that is done, you can look into the prediction functions and optimize
that or tweak the bits and pieces there and decide which predictors work
best for a particular workload.
As long as you just look into a particular predictor function and do not
address the underlying conceptual issues first, the outcome is very much
predictable: It's going to be useless crap.
Thanks,
tglx
[toc] | [prev] | [next] | [standalone]
| From | Arjan van de Ven <arjan@linux.intel.com> |
|---|---|
| Date | 2017-07-20 15:50 +0200 |
| Message-ID | <u5k02-8cN-35@gated-at.bofh.it> |
| In reply to | #1692546 |
On 7/20/2017 1:11 AM, Thomas Gleixner wrote: > On Thu, 20 Jul 2017, Li, Aubrey wrote: >> Don't get me wrong, even if a fast path is acceptable, we still need to >> figure out if the coming idle is short and when to switch. I'm just worried >> about if irq timings is not an ideal statistics, we have to skip it too. > > There is no ideal solution ever. > > Lets sit back and look at that from the big picture first before dismissing > a particular item upfront. > > The current NOHZ implementation does: > > predict = nohz_predict(timers, rcu, arch, irqwork); > > if ((predict - now) > X) > stop_tick() > > The C-State machinery does something like: > > predict = cstate_predict(next_timer, scheduler); > > cstate = cstate_select(predict); > > That disconnect is part of the problem. What we really want is: > > predict = idle_predict(timers, rcu, arch, irqwork, scheduler, irq timings); two separate predictors is clearly a recipe for badness. (likewise, C and P states try to estimate "performance sensitivity" and sometimes estimate in opposite directions) to be honest, performance sensitivity estimation is probably 10x more critical for C state selection than idle duration; a lot of modern hardware will do the energy efficiency stuff in a microcontroller when it coordinates between multiple cores in the system on C and P states. (both x86 and ARM have such microcontroller nowadays, at least for the higher performance designs)
[toc] | [prev] | [next] | [standalone]
| From | Thomas Gleixner <tglx@linutronix.de> |
|---|---|
| Date | 2017-07-18 09:30 +0200 |
| Subject | Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods |
| Message-ID | <u4v7c-7Sa-19@gated-at.bofh.it> |
| In reply to | #1689787 |
On Mon, 17 Jul 2017, Andi Kleen wrote: > On Tue, Jul 18, 2017 at 08:43:53AM +0200, Thomas Gleixner wrote: > > On Mon, 17 Jul 2017, Andi Kleen wrote: > > > > > > We need a tradeoff here IMHO. I'll check Daniel's work to understand how/if > > > > it's better than menu governor. > > > > > > I still would like to see how the fast path without the C1 heuristic works. > > > > > > Fast pathing is a different concept from a better predictor. IMHO we need > > > both, but the first is likely lower hanging fruit. > > > > Hacking something on the side is always the lower hanging fruit as it > > avoids solving the hard problems. As Peter said already, that's not going > > to happen unless there is a real technical reason why the general path > > cannot be fixed. So far there is no proof for that. > > You didn't look at Aubrey's data? I did, but that data is no proof that it is unfixable. It's just data describing the current situation, not more not less. > There are some unavoidable slow operations in the current path -- e.g. That's the whole point: current path, IOW current implementation. This implementation is not set in stone and we rather fix it than just creating a side channel and leave everything else as is. Thanks, tglx
[toc] | [prev] | [next] | [standalone]
| From | "Li, Aubrey" <aubrey.li@linux.intel.com> |
|---|---|
| Date | 2017-07-18 09:00 +0200 |
| Message-ID | <u4uEa-7rF-15@gated-at.bofh.it> |
| In reply to | #1689778 |
On 2017/7/18 14:43, Thomas Gleixner wrote: > On Mon, 17 Jul 2017, Andi Kleen wrote: > >>> We need a tradeoff here IMHO. I'll check Daniel's work to understand how/if >>> it's better than menu governor. >> >> I still would like to see how the fast path without the C1 heuristic works. >> >> Fast pathing is a different concept from a better predictor. IMHO we need >> both, but the first is likely lower hanging fruit. > > Hacking something on the side is always the lower hanging fruit as it > avoids solving the hard problems. As Peter said already, that's not going > to happen unless there is a real technical reason why the general path > cannot be fixed. So far there is no proof for that. > Let me try to make a summary, please correct me if I was wrong. 1) for quiet_vmstat, we are agreed to move to another place where tick is really stopped. 2) for rcu idle enter/exit, I measured the details which Paul provided, and the result matches with what I have measured before, nothing notable found. But it still makes more sense if we can make rcu idle enter/exit hooked with tick off. (it's possible other workloads behave differently) 3) for tick nohz idle, we want to skip if the coming idle is short. If we can skip the tick nohz idle, we then skip all the items depending on it. But, there are two hard points: 3.1) how to compute the period of the coming idle. My current proposal is to use two factors in the current idle menu governor. There are two possible options from Peter and Thomas, the one is to use scheduler idle estimate, which is task activity based, the other is to use the statistics generated from irq timings work. 3.2) how to determine if the idle is short or long. My current proposal is to use a tunable value via /sys, while Peter prefers an auto-adjust mechanism. I didn't get the details of an auto-adjust mechanism yet 4) for idle loop, my proposal introduces a simple one to use default idle routine directly, while Peter and Thomas suggest we fix c-state selection in the existing idle path. Thanks, -Aubrey
[toc] | [prev] | [next] | [standalone]
| From | "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> |
|---|---|
| Date | 2017-07-18 17:30 +0200 |
| Message-ID | <u4CBH-45e-9@gated-at.bofh.it> |
| In reply to | #1689788 |
On Tue, Jul 18, 2017 at 02:56:47PM +0800, Li, Aubrey wrote: > On 2017/7/18 14:43, Thomas Gleixner wrote: > > On Mon, 17 Jul 2017, Andi Kleen wrote: > > > >>> We need a tradeoff here IMHO. I'll check Daniel's work to understand how/if > >>> it's better than menu governor. > >> > >> I still would like to see how the fast path without the C1 heuristic works. > >> > >> Fast pathing is a different concept from a better predictor. IMHO we need > >> both, but the first is likely lower hanging fruit. > > > > Hacking something on the side is always the lower hanging fruit as it > > avoids solving the hard problems. As Peter said already, that's not going > > to happen unless there is a real technical reason why the general path > > cannot be fixed. So far there is no proof for that. > > > Let me try to make a summary, please correct me if I was wrong. > > 1) for quiet_vmstat, we are agreed to move to another place where tick is > really stopped. > > 2) for rcu idle enter/exit, I measured the details which Paul provided, and > the result matches with what I have measured before, nothing notable found. > But it still makes more sense if we can make rcu idle enter/exit hooked with > tick off. (it's possible other workloads behave differently) Again, assuming that RCU is informed of CPUs in the kernel, regardless of whether or not the tick is on that that point in time. Thanx, Paul > 3) for tick nohz idle, we want to skip if the coming idle is short. If we can > skip the tick nohz idle, we then skip all the items depending on it. But, there > are two hard points: > > 3.1) how to compute the period of the coming idle. My current proposal is to > use two factors in the current idle menu governor. There are two possible > options from Peter and Thomas, the one is to use scheduler idle estimate, which > is task activity based, the other is to use the statistics generated from irq > timings work. > > 3.2) how to determine if the idle is short or long. My current proposal is to > use a tunable value via /sys, while Peter prefers an auto-adjust mechanism. I > didn't get the details of an auto-adjust mechanism yet > > 4) for idle loop, my proposal introduces a simple one to use default idle > routine directly, while Peter and Thomas suggest we fix c-state selection > in the existing idle path. > > Thanks, > -Aubrey >
[toc] | [prev] | [next] | [standalone]
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
Back to top | Article view | linux.kernel
csiph-web