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

2018-12-08 Thread Doug Smythies
On 2018.12.08 02:23 Giovanni Gherdovich wrote: > sorry for the late reply, this week I was traveling. No Problem. Thanks very much for your very detailed reply, which obviously took considerable time to write. While I was making progress, your instructions really fill in some gaps and mistakes I

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

2018-12-08 Thread Giovanni Gherdovich
Hello Doug, sorry for the late reply, this week I was traveling. First off, thank you for trying out MMTests; I admit the documentation is somewhat incomplete. I'm going to give you an overview of how I run benchmarks with MMTests and how do I print comparisons, hoping this can address your quest

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

2018-12-07 Thread Mel Gorman
On Mon, Dec 03, 2018 at 08:23:56AM -0800, Doug Smythies wrote: > In the README file, I did see that for reporting I am > somehow supposed to use compare-kernels.sh, but > I couldn't figure that out. > cd work/log ../../compare-kernels.sh > By the way, I am running these tests as a regular user,

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

2018-12-06 Thread Rafael J. Wysocki
On Thu, Dec 6, 2018 at 12:06 AM Doug Smythies wrote: > > On 2018.12.03 03:48 Rafael J. Wysocki wrote: > > >>> There is an additional issue where if idle state 0 is disabled (with the > >>> above suggested code patch), > >>> idle state usage seems to fall to deeper states than idle state 1. > >>>

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

2018-12-05 Thread Doug Smythies
On 2018.12.03 03:48 Rafael J. Wysocki wrote: >>> There is an additional issue where if idle state 0 is disabled (with the >>> above suggested code patch), >>> idle state usage seems to fall to deeper states than idle state 1. >>> This is not the expected behaviour. >> >> No, it isn't. >> >>> Ke

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

2018-12-03 Thread Rafael J. Wysocki
On Thursday, November 29, 2018 12:20:07 AM CET Doug Smythies wrote: > On 2018.11.23 02:36 Rafael J. Wysocki wrote: > > v5 -> v6: > * Avoid applying poll_time_limit to non-polling idle states by mistake. > * Use idle duration measured by the governor for everything (as it likely is >more accu

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

2018-12-03 Thread Rafael J. Wysocki
On Friday, November 30, 2018 9:51:19 AM CET Rafael J. Wysocki wrote: > Hi Doug, > > On Fri, Nov 30, 2018 at 8:49 AM Doug Smythies wrote: > > > > Hi Rafael, > > > > On 2018.11.23 02:36 Rafael J. Wysocki wrote: > > > > ... [snip]... > > > > > +/** > > > + * teo_find_shallower_state - Find shallower

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

2018-12-03 Thread Rafael J. Wysocki
On Saturday, December 1, 2018 3:18:24 PM CET Giovanni Gherdovich wrote: > On Fri, 2018-11-23 at 11:35 +0100, Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki > > [cut] > > > > [snip] > > [NOTE: the tables in this message are quite wide. If this doesn't get to you > properly formatted you

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

2018-12-03 Thread Doug Smythies
Hi Giovanni, Perhaps I should go off-list for this, not sure. I had the thought that I should be able to get similar results as your "8x-SKYLAKE-UMA" on my test computer, i7-2600K. Or that at least it was worth trying, just to see. I couldn't find the same or similar test on Phoronix, and my atte

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

2018-12-01 Thread Giovanni Gherdovich
On Fri, 2018-11-23 at 11:35 +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

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

2018-11-30 Thread Rafael J. Wysocki
Hi Doug, On Fri, Nov 30, 2018 at 8:49 AM Doug Smythies wrote: > > Hi Rafael, > > On 2018.11.23 02:36 Rafael J. Wysocki wrote: > > ... [snip]... > > > +/** > > + * teo_find_shallower_state - Find shallower idle state matching given > > duration. > > + * @drv: cpuidle driver containing state data.

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

2018-11-29 Thread Doug Smythies
Hi Rafael, On 2018.11.23 02:36 Rafael J. Wysocki wrote: ... [snip]... > +/** > + * teo_find_shallower_state - Find shallower idle state matching given > duration. > + * @drv: cpuidle driver containing state data. > + * @dev: Target CPU. > + * @state_idx: Index of the capping idle state. > + * @

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

2018-11-29 Thread Rafael J. Wysocki
Hi Doug, On Thu, Nov 29, 2018 at 12:20 AM Doug Smythies wrote: > > On 2018.11.23 02:36 Rafael J. Wysocki wrote: > > v5 -> v6: > * Avoid applying poll_time_limit to non-polling idle states by mistake. > * Use idle duration measured by the governor for everything (as it likely is >more accura

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

2018-11-28 Thread Doug Smythies
On 2018.11.23 02:36 Rafael J. Wysocki wrote: v5 -> v6: * Avoid applying poll_time_limit to non-polling idle states by mistake. * Use idle duration measured by the governor for everything (as it likely is more accurate than the one measured by the core). -- above missing-- (see follow up e-ma

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

2018-11-23 Thread Rafael J. Wysocki
On Friday, November 23, 2018 11:35:38 AM CET 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 othe