Re: [RFC 08/14] sched/tune: add detailed documentation

On 16 September 2015 at 11:26, Juri Lelli wrote: > > Hi Steve, > > thanks a lot for this interesting discussion. > > On 16/09/15 00:55, Steve Muckle wrote: > > On 09/15/2015 08:00 AM, Patrick Bellasi wrote: > >>> Agreed, though I also think those tunable values might also change for a > >>> given

Re: [RFC 08/14] sched/tune: add detailed documentation

On Wed, Sep 16, 2015 at 12:55:12AM +0100, Steve Muckle wrote: > On 09/15/2015 08:00 AM, Patrick Bellasi wrote: > >> Agreed, though I also think those tunable values might also change for a > >> given set of tasks in different circumstances. > > > > Could you provide an example? > > > > In my view

Re: [RFC 08/14] sched/tune: add detailed documentation

Hi Steve, thanks a lot for this interesting discussion. On 16/09/15 00:55, Steve Muckle wrote: > On 09/15/2015 08:00 AM, Patrick Bellasi wrote: >>> Agreed, though I also think those tunable values might also change for a >>> given set of tasks in different circumstances. >> >> Could you provide

Re: [RFC 08/14] sched/tune: add detailed documentation

* Steve Muckle wrote: > On 09/15/2015 08:19 AM, Peter Zijlstra wrote: > > Please flip the argument around; providing lots of knobs for vendors to > > do $magic with is _NOT_ a good thing. > > > > The whole out-of-tree cpufreq governor hack fest Android thing is a > > complete and utter fail on

Re: [RFC 08/14] sched/tune: add detailed documentation

* Steve Muckle wrote: > On 09/15/2015 08:19 AM, Peter Zijlstra wrote: > > Please flip the argument around; providing lots of knobs for vendors to > > do $magic with is _NOT_ a good thing. > > > > The whole out-of-tree cpufreq governor hack fest Android thing is a > >

Re: [RFC 08/14] sched/tune: add detailed documentation

Hi Steve, thanks a lot for this interesting discussion. On 16/09/15 00:55, Steve Muckle wrote: > On 09/15/2015 08:00 AM, Patrick Bellasi wrote: >>> Agreed, though I also think those tunable values might also change for a >>> given set of tasks in different circumstances. >> >> Could you provide

Re: [RFC 08/14] sched/tune: add detailed documentation

On Wed, Sep 16, 2015 at 12:55:12AM +0100, Steve Muckle wrote: > On 09/15/2015 08:00 AM, Patrick Bellasi wrote: > >> Agreed, though I also think those tunable values might also change for a > >> given set of tasks in different circumstances. > > > > Could you provide an example? > > > > In my view

Re: [RFC 08/14] sched/tune: add detailed documentation

On 16 September 2015 at 11:26, Juri Lelli wrote: > > Hi Steve, > > thanks a lot for this interesting discussion. > > On 16/09/15 00:55, Steve Muckle wrote: > > On 09/15/2015 08:00 AM, Patrick Bellasi wrote: > >>> Agreed, though I also think those tunable values might also

Re: [RFC 08/14] sched/tune: add detailed documentation

On 09/15/2015 08:19 AM, Peter Zijlstra wrote: > Please flip the argument around; providing lots of knobs for vendors to > do $magic with is _NOT_ a good thing. > > The whole out-of-tree cpufreq governor hack fest Android thing is a > complete and utter fail on all levels. Its the embedded, ship,

Re: [RFC 08/14] sched/tune: add detailed documentation

On 09/15/2015 08:00 AM, Patrick Bellasi wrote: >> Agreed, though I also think those tunable values might also change for a >> given set of tasks in different circumstances. > > Could you provide an example? > > In my view the per-task support should be exploited just for quite > specialized

Re: [RFC 08/14] sched/tune: add detailed documentation

On Tue, Sep 15, 2015 at 04:00:45PM +0100, Patrick Bellasi wrote: > > I'm curious about the drive for one tunable. Is that something there's > > specifically been a broad call for? Don't get me wrong, I'm all for > > simplification and cleanup, if the flexibility and used features can be > >

Re: [RFC 08/14] sched/tune: add detailed documentation

On Mon, Sep 14, 2015 at 09:00:51PM +0100, Steve Muckle wrote: > Hi Patrick, > > On 09/11/2015 04:09 AM, Patrick Bellasi wrote: > >> It's also worth noting that mobile vendors typically add all sorts of > >> hacks on top of the existing cpufreq governors which further complicate > >> policy. > >

Re: [RFC 08/14] sched/tune: add detailed documentation

On 09/15/2015 08:00 AM, Patrick Bellasi wrote: >> Agreed, though I also think those tunable values might also change for a >> given set of tasks in different circumstances. > > Could you provide an example? > > In my view the per-task support should be exploited just for quite > specialized

Re: [RFC 08/14] sched/tune: add detailed documentation

On 09/15/2015 08:19 AM, Peter Zijlstra wrote: > Please flip the argument around; providing lots of knobs for vendors to > do $magic with is _NOT_ a good thing. > > The whole out-of-tree cpufreq governor hack fest Android thing is a > complete and utter fail on all levels. Its the embedded, ship,

Re: [RFC 08/14] sched/tune: add detailed documentation

On Mon, Sep 14, 2015 at 09:00:51PM +0100, Steve Muckle wrote: > Hi Patrick, > > On 09/11/2015 04:09 AM, Patrick Bellasi wrote: > >> It's also worth noting that mobile vendors typically add all sorts of > >> hacks on top of the existing cpufreq governors which further complicate > >> policy. > >

Re: [RFC 08/14] sched/tune: add detailed documentation

On Tue, Sep 15, 2015 at 04:00:45PM +0100, Patrick Bellasi wrote: > > I'm curious about the drive for one tunable. Is that something there's > > specifically been a broad call for? Don't get me wrong, I'm all for > > simplification and cleanup, if the flexibility and used features can be > >

Re: [RFC 08/14] sched/tune: add detailed documentation

Hi Patrick, On 09/11/2015 04:09 AM, Patrick Bellasi wrote: >> It's also worth noting that mobile vendors typically add all sorts of >> hacks on top of the existing cpufreq governors which further complicate >> policy. > > Could it be that many of the hacks introduced by vendors are just > there

Re: [RFC 08/14] sched/tune: add detailed documentation

Hi Patrick, On 09/11/2015 04:09 AM, Patrick Bellasi wrote: >> It's also worth noting that mobile vendors typically add all sorts of >> hacks on top of the existing cpufreq governors which further complicate >> policy. > > Could it be that many of the hacks introduced by vendors are just > there

Re: [RFC 08/14] sched/tune: add detailed documentation

On Wed, Sep 09, 2015 at 09:16:10PM +0100, Steve Muckle wrote: > Hi Patrick, Hi Steve, > On 09/03/2015 02:18 AM, Patrick Bellasi wrote: > > In my view, one of the main goals of sched-DVFS is actually that to be > > a solid and generic replacement of different CPUFreq governors. > > Being driven

Re: [RFC 08/14] sched/tune: add detailed documentation

On Wed, Sep 09, 2015 at 09:16:10PM +0100, Steve Muckle wrote: > Hi Patrick, Hi Steve, > On 09/03/2015 02:18 AM, Patrick Bellasi wrote: > > In my view, one of the main goals of sched-DVFS is actually that to be > > a solid and generic replacement of different CPUFreq governors. > > Being driven

Re: [RFC 08/14] sched/tune: add detailed documentation

Hi Patrick, On 09/03/2015 02:18 AM, Patrick Bellasi wrote: > In my view, one of the main goals of sched-DVFS is actually that to be > a solid and generic replacement of different CPUFreq governors. > Being driven by the scheduler, sched-DVFS can exploit information on > CPU demand of active tasks

Re: [RFC 08/14] sched/tune: add detailed documentation

Hi Patrick, On 09/03/2015 02:18 AM, Patrick Bellasi wrote: > In my view, one of the main goals of sched-DVFS is actually that to be > a solid and generic replacement of different CPUFreq governors. > Being driven by the scheduler, sched-DVFS can exploit information on > CPU demand of active tasks

Re: [RFC 08/14] sched/tune: add detailed documentation

Hi Patrick, Please find my replies inline. On Thu, Sep 3, 2015 at 5:18 PM, Patrick Bellasi wrote: > On Wed, Sep 02, 2015 at 07:49:58AM +0100, Ricky Liang wrote: >> Hi Patrick, > > Hi Ricky, > >> I wonder if this can replace the boost function in the interactive >> governor [0], which is widely

Re: [RFC 08/14] sched/tune: add detailed documentation

Hi Patrick, Please find my replies inline. On Thu, Sep 3, 2015 at 5:18 PM, Patrick Bellasi wrote: > On Wed, Sep 02, 2015 at 07:49:58AM +0100, Ricky Liang wrote: >> Hi Patrick, > > Hi Ricky, > >> I wonder if this can replace the boost function in the interactive >>

Re: [RFC 08/14] sched/tune: add detailed documentation

On Wed, Sep 02, 2015 at 07:49:58AM +0100, Ricky Liang wrote: > Hi Patrick, Hi Ricky, > I wonder if this can replace the boost function in the interactive > governor [0], which is widely used in both Android and ChromeOS > kernels. In my view, one of the main goals of sched-DVFS is actually that

Re: [RFC 08/14] sched/tune: add detailed documentation

On Wed, Sep 02, 2015 at 07:49:58AM +0100, Ricky Liang wrote: > Hi Patrick, Hi Ricky, > I wonder if this can replace the boost function in the interactive > governor [0], which is widely used in both Android and ChromeOS > kernels. In my view, one of the main goals of sched-DVFS is actually that

Re: [RFC,08/14] sched/tune: add detailed documentation

Hi Patrick, I wonder if this can replace the boost function in the interactive governor [0], which is widely used in both Android and ChromeOS kernels. My understanding is that the boost in interactive governor is to simply raise the OPP on selected cores. The SchedTune boost works by adding a

Re: [RFC,08/14] sched/tune: add detailed documentation

Hi Patrick, I wonder if this can replace the boost function in the interactive governor [0], which is widely used in both Android and ChromeOS kernels. My understanding is that the boost in interactive governor is to simply raise the OPP on selected cores. The SchedTune boost works by adding a