On Fri, 2 Sep 2016, Juri Lelli wrote:
> On 01/09/16 14:48, Steve Muckle wrote:
> > On Wed, Aug 31, 2016 at 06:00:02PM +0100, Juri Lelli wrote:
> > > > Another problem is that we have many semi related knobs; we have the
> > > > global RT runtime limit knob, but that doesn't affect cpufreq (maybe
On Fri, 2 Sep 2016, Juri Lelli wrote:
> On 01/09/16 14:48, Steve Muckle wrote:
> > On Wed, Aug 31, 2016 at 06:00:02PM +0100, Juri Lelli wrote:
> > > > Another problem is that we have many semi related knobs; we have the
> > > > global RT runtime limit knob, but that doesn't affect cpufreq (maybe
On 01/09/16 14:48, Steve Muckle wrote:
> On Wed, Aug 31, 2016 at 06:00:02PM +0100, Juri Lelli wrote:
> > > Another problem is that we have many semi related knobs; we have the
> > > global RT runtime limit knob, but that doesn't affect cpufreq (maybe it
> > > should)
> >
> > Maybe we could create
On 01/09/16 14:48, Steve Muckle wrote:
> On Wed, Aug 31, 2016 at 06:00:02PM +0100, Juri Lelli wrote:
> > > Another problem is that we have many semi related knobs; we have the
> > > global RT runtime limit knob, but that doesn't affect cpufreq (maybe it
> > > should)
> >
> > Maybe we could create
On Wed, 31 Aug 2016, Peter Zijlstra wrote:
> On Wed, Aug 31, 2016 at 06:28:10PM +0200, Thomas Gleixner wrote:
> > > That is the way it's been with cpufreq and many systems (including all
> > > mobile devices) rely on that to not destroy power. RT + variable cpufreq
> > > is not deterministic.
> >
On Wed, 31 Aug 2016, Peter Zijlstra wrote:
> On Wed, Aug 31, 2016 at 06:28:10PM +0200, Thomas Gleixner wrote:
> > > That is the way it's been with cpufreq and many systems (including all
> > > mobile devices) rely on that to not destroy power. RT + variable cpufreq
> > > is not deterministic.
> >
On Wed, Aug 31, 2016 at 06:00:02PM +0100, Juri Lelli wrote:
> > Another problem is that we have many semi related knobs; we have the
> > global RT runtime limit knob, but that doesn't affect cpufreq (maybe it
> > should)
>
> Maybe we could create this sort of link when using the cgroup RT
>
On Wed, Aug 31, 2016 at 06:00:02PM +0100, Juri Lelli wrote:
> > Another problem is that we have many semi related knobs; we have the
> > global RT runtime limit knob, but that doesn't affect cpufreq (maybe it
> > should)
>
> Maybe we could create this sort of link when using the cgroup RT
>
On Wed, Aug 31, 2016 at 06:00:02PM +0100, Juri Lelli wrote:
> On 31/08/16 18:40, Peter Zijlstra wrote:
> > Another problem is that we have many semi related knobs; we have the
> > global RT runtime limit knob, but that doesn't affect cpufreq (maybe it
> > should)
>
> Maybe we could create this
On Wed, Aug 31, 2016 at 06:00:02PM +0100, Juri Lelli wrote:
> On 31/08/16 18:40, Peter Zijlstra wrote:
> > Another problem is that we have many semi related knobs; we have the
> > global RT runtime limit knob, but that doesn't affect cpufreq (maybe it
> > should)
>
> Maybe we could create this
On Wednesday, August 31, 2016 06:40:09 PM Peter Zijlstra wrote:
> On Wed, Aug 31, 2016 at 06:28:10PM +0200, Thomas Gleixner wrote:
> > > That is the way it's been with cpufreq and many systems (including all
> > > mobile devices) rely on that to not destroy power. RT + variable cpufreq
> > > is
On Wednesday, August 31, 2016 06:40:09 PM Peter Zijlstra wrote:
> On Wed, Aug 31, 2016 at 06:28:10PM +0200, Thomas Gleixner wrote:
> > > That is the way it's been with cpufreq and many systems (including all
> > > mobile devices) rely on that to not destroy power. RT + variable cpufreq
> > > is
On Wed, 31 Aug 2016, Steve Muckle wrote:
> On Wed, Aug 31, 2016 at 04:39:07PM +0200, Peter Zijlstra wrote:
> > On Fri, Aug 26, 2016 at 11:40:48AM -0700, Steve Muckle wrote:
> > > A policy of going to fmax on any RT activity will be detrimental
> > > for power on many platforms. Often RT accounts
On Wed, 31 Aug 2016, Steve Muckle wrote:
> On Wed, Aug 31, 2016 at 04:39:07PM +0200, Peter Zijlstra wrote:
> > On Fri, Aug 26, 2016 at 11:40:48AM -0700, Steve Muckle wrote:
> > > A policy of going to fmax on any RT activity will be detrimental
> > > for power on many platforms. Often RT accounts
On 31/08/16 18:40, Peter Zijlstra wrote:
> On Wed, Aug 31, 2016 at 06:28:10PM +0200, Thomas Gleixner wrote:
> > > That is the way it's been with cpufreq and many systems (including all
> > > mobile devices) rely on that to not destroy power. RT + variable cpufreq
> > > is not deterministic.
> > >
On 31/08/16 18:40, Peter Zijlstra wrote:
> On Wed, Aug 31, 2016 at 06:28:10PM +0200, Thomas Gleixner wrote:
> > > That is the way it's been with cpufreq and many systems (including all
> > > mobile devices) rely on that to not destroy power. RT + variable cpufreq
> > > is not deterministic.
> > >
On Wed, Aug 31, 2016 at 06:28:10PM +0200, Thomas Gleixner wrote:
> > That is the way it's been with cpufreq and many systems (including all
> > mobile devices) rely on that to not destroy power. RT + variable cpufreq
> > is not deterministic.
> >
> > Given we don't have good constraints on RT
On Wed, Aug 31, 2016 at 06:28:10PM +0200, Thomas Gleixner wrote:
> > That is the way it's been with cpufreq and many systems (including all
> > mobile devices) rely on that to not destroy power. RT + variable cpufreq
> > is not deterministic.
> >
> > Given we don't have good constraints on RT
On Wed, Aug 31, 2016 at 04:39:07PM +0200, Peter Zijlstra wrote:
> On Fri, Aug 26, 2016 at 11:40:48AM -0700, Steve Muckle wrote:
> > A policy of going to fmax on any RT activity will be detrimental
> > for power on many platforms. Often RT accounts for only a small amount
> > of CPU activity so
On Wed, Aug 31, 2016 at 04:39:07PM +0200, Peter Zijlstra wrote:
> On Fri, Aug 26, 2016 at 11:40:48AM -0700, Steve Muckle wrote:
> > A policy of going to fmax on any RT activity will be detrimental
> > for power on many platforms. Often RT accounts for only a small amount
> > of CPU activity so
On Wed, Aug 31, 2016 at 03:31:07AM +0200, Rafael J. Wysocki wrote:
> On Friday, August 26, 2016 11:40:48 AM Steve Muckle wrote:
> > A policy of going to fmax on any RT activity will be detrimental
> > for power on many platforms. Often RT accounts for only a small amount
> > of CPU activity so
On Wed, Aug 31, 2016 at 03:31:07AM +0200, Rafael J. Wysocki wrote:
> On Friday, August 26, 2016 11:40:48 AM Steve Muckle wrote:
> > A policy of going to fmax on any RT activity will be detrimental
> > for power on many platforms. Often RT accounts for only a small amount
> > of CPU activity so
On Fri, Aug 26, 2016 at 11:40:48AM -0700, Steve Muckle wrote:
> A policy of going to fmax on any RT activity will be detrimental
> for power on many platforms. Often RT accounts for only a small amount
> of CPU activity so sending the CPU frequency to fmax is overkill. Worse
> still, some
On Fri, Aug 26, 2016 at 11:40:48AM -0700, Steve Muckle wrote:
> A policy of going to fmax on any RT activity will be detrimental
> for power on many platforms. Often RT accounts for only a small amount
> of CPU activity so sending the CPU frequency to fmax is overkill. Worse
> still, some
On Friday, August 26, 2016 11:40:48 AM Steve Muckle wrote:
> A policy of going to fmax on any RT activity will be detrimental
> for power on many platforms. Often RT accounts for only a small amount
> of CPU activity so sending the CPU frequency to fmax is overkill. Worse
> still, some platforms
On Friday, August 26, 2016 11:40:48 AM Steve Muckle wrote:
> A policy of going to fmax on any RT activity will be detrimental
> for power on many platforms. Often RT accounts for only a small amount
> of CPU activity so sending the CPU frequency to fmax is overkill. Worse
> still, some platforms
A policy of going to fmax on any RT activity will be detrimental
for power on many platforms. Often RT accounts for only a small amount
of CPU activity so sending the CPU frequency to fmax is overkill. Worse
still, some platforms may not be able to even complete the CPU frequency
change before the
A policy of going to fmax on any RT activity will be detrimental
for power on many platforms. Often RT accounts for only a small amount
of CPU activity so sending the CPU frequency to fmax is overkill. Worse
still, some platforms may not be able to even complete the CPU frequency
change before the
28 matches
Mail list logo
