Re: [RFC/RFT][PATCH v3] cpuidle: New timer events oriented governor for tickless systems

2018-11-14 Thread Rafael J. Wysocki
On Wed, Nov 14, 2018 at 7:26 AM Doug Smythies wrote: > > On 2018.11.08 00:00 Rafael J. Wysocki wrote: > > On Wednesday, November 7, 2018 6:04:12 PM CET Doug Smythies wrote: > >> On 2018.11.04 08:31 Rafael J. Wysocki wrote: > > ...[snip]... > >> The results are: > >> http://fast.smythies.com/linux-

RE: [RFC/RFT][PATCH v3] cpuidle: New timer events oriented governor for tickless systems

2018-11-13 Thread Doug Smythies
On 2018.11.08 00:00 Rafael J. Wysocki wrote: > On Wednesday, November 7, 2018 6:04:12 PM CET Doug Smythies wrote: >> On 2018.11.04 08:31 Rafael J. Wysocki wrote: ...[snip]... >> The results are: >> http://fast.smythies.com/linux-pm/k420/k420-dbench-teo3.htm >> http://fast.smythies.com/linux-pm/k42

RE: [RFC/RFT][PATCH v3] cpuidle: New timer events oriented governor for tickless systems

2018-11-11 Thread Doug Smythies
On 2018.11.10 13:48 Doug Smythies wrote: > On 2018.11.07 09:04 Doug Smythies wrote: > >> The Phoronix dbench test was run under the option to run all >> the tests, instead of just one number of clients. This was done >> with a reference/baseline kernel of 4.20-rc1, and also with this >> TEO version

RE: [RFC/RFT][PATCH v3] cpuidle: New timer events oriented governor for tickless systems

2018-11-10 Thread Doug Smythies
On 2018.11.07 09:04 Doug Smythies wrote: > The Phoronix dbench test was run under the option to run all > the tests, instead of just one number of clients. This was done > with a reference/baseline kernel of 4.20-rc1, and also with this > TEO version 3 patch. The tests were also repeated with trac

Re: [RFC/RFT][PATCH v3] cpuidle: New timer events oriented governor for tickless systems

2018-11-08 Thread Rafael J. Wysocki
On Wednesday, November 7, 2018 6:04:12 PM CET Doug Smythies wrote: > On 2018.11.04 08:31 Rafael J. Wysocki wrote: > > > v2 -> v3: > > * Simplify the pattern detection code and make it return a value > > lower than the time to the closest timer if the majority of recent > > idle intervals a

RE: [RFC/RFT][PATCH v3] cpuidle: New timer events oriented governor for tickless systems

2018-11-07 Thread Doug Smythies
On 2018.11.04 08:31 Rafael J. Wysocki wrote: > v2 -> v3: > * Simplify the pattern detection code and make it return a value > lower than the time to the closest timer if the majority of recent > idle intervals are below it regardless of their variance (that should > cause it to b

Re: [RFC/RFT][PATCH v3] cpuidle: New timer events oriented governor for tickless systems

2018-11-07 Thread Rafael J. Wysocki
On Wed, Nov 7, 2018 at 9:59 AM Peter Zijlstra wrote: > > On Wed, Nov 07, 2018 at 12:39:31AM +0100, Rafael J. Wysocki wrote: > > On Tue, Nov 6, 2018 at 8:51 PM Peter Zijlstra wrote: > > > > > > On Tue, Nov 06, 2018 at 07:19:24PM +0100, Rafael J. Wysocki wrote: > > > > On Tue, Nov 6, 2018 at 6:04 P

Re: [RFC/RFT][PATCH v3] cpuidle: New timer events oriented governor for tickless systems

2018-11-07 Thread Daniel Lezcano
On 07/11/2018 00:39, Rafael J. Wysocki wrote: > On Tue, Nov 6, 2018 at 8:51 PM Peter Zijlstra wrote: >> >> On Tue, Nov 06, 2018 at 07:19:24PM +0100, Rafael J. Wysocki wrote: >>> On Tue, Nov 6, 2018 at 6:04 PM Peter Zijlstra wrote: >> Instead of this detector; why haven't you used the code fr

Re: [RFC/RFT][PATCH v3] cpuidle: New timer events oriented governor for tickless systems

2018-11-07 Thread Peter Zijlstra
On Wed, Nov 07, 2018 at 12:39:31AM +0100, Rafael J. Wysocki wrote: > On Tue, Nov 6, 2018 at 8:51 PM Peter Zijlstra wrote: > > > > On Tue, Nov 06, 2018 at 07:19:24PM +0100, Rafael J. Wysocki wrote: > > > On Tue, Nov 6, 2018 at 6:04 PM Peter Zijlstra > > > wrote: > > > > > > Instead of this detect

Re: [RFC/RFT][PATCH v3] cpuidle: New timer events oriented governor for tickless systems

2018-11-06 Thread Rafael J. Wysocki
On Tue, Nov 6, 2018 at 8:51 PM Peter Zijlstra wrote: > > On Tue, Nov 06, 2018 at 07:19:24PM +0100, Rafael J. Wysocki wrote: > > On Tue, Nov 6, 2018 at 6:04 PM Peter Zijlstra wrote: > > > > Instead of this detector; why haven't you used the code from > > > kernel/irq/timings.c ? > > > > Because it

Re: [RFC/RFT][PATCH v3] cpuidle: New timer events oriented governor for tickless systems

2018-11-06 Thread Peter Zijlstra
On Tue, Nov 06, 2018 at 07:19:24PM +0100, Rafael J. Wysocki wrote: > On Tue, Nov 6, 2018 at 6:04 PM Peter Zijlstra wrote: > > Instead of this detector; why haven't you used the code from > > kernel/irq/timings.c ? > > Because it doesn't help much AFAICS. > > Wakeups need not be interrupts in pa

Re: [RFC/RFT][PATCH v3] cpuidle: New timer events oriented governor for tickless systems

2018-11-06 Thread Rafael J. Wysocki
On Tue, Nov 6, 2018 at 6:04 PM Peter Zijlstra wrote: > > On Sun, Nov 04, 2018 at 05:31:20PM +0100, Rafael J. Wysocki wrote: > > + * - If there is a pattern of 5 or more recent non-timer wakeups earlier > > than > > + * the closest timer event, expect one more of them to occur and use the > > +

Re: [RFC/RFT][PATCH v3] cpuidle: New timer events oriented governor for tickless systems

2018-11-06 Thread Peter Zijlstra
On Sun, Nov 04, 2018 at 05:31:20PM +0100, Rafael J. Wysocki wrote: > + * - If there is a pattern of 5 or more recent non-timer wakeups earlier than > + * the closest timer event, expect one more of them to occur and use the > + * average of the idle duration values corresponding to them to sele

Re: [RFC/RFT][PATCH v3] cpuidle: New timer events oriented governor for tickless systems

2018-11-06 Thread Rafael J. Wysocki
On Monday, November 5, 2018 8:32:51 PM CET Giovanni Gherdovich wrote: > On Sun, 2018-11-04 at 17:31 +0100, Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki > > [cut] > > + > > +/** > > + * teo_update - Update CPU data after wakeup. > > + * @drv: cpuidle driver containing state data. > > + *

Re: [RFC/RFT][PATCH v3] cpuidle: New timer events oriented governor for tickless systems

2018-11-05 Thread Giovanni Gherdovich
On Sun, 2018-11-04 at 17:31 +0100, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki >  > The venerable menu governor does some thigns that are quite > questionable in my view.  First, it includes timer wakeups in > the pattern detection data and mixes them up with wakeups from > other sources wh