On 18 May 2018 at 17:16, Dietmar Eggemann wrote:
> On 05/18/2018 10:36 AM, Peter Zijlstra wrote:
>>
>>
>> Replying to the latest version available; given the current interest I
>> figure I'd re-read some of the old threads and look at this stuff again.
>>
>> On Fri, Apr
On 18 May 2018 at 17:16, Dietmar Eggemann wrote:
> On 05/18/2018 10:36 AM, Peter Zijlstra wrote:
>>
>>
>> Replying to the latest version available; given the current interest I
>> figure I'd re-read some of the old threads and look at this stuff again.
>>
>> On Fri, Apr 28, 2017 at 04:23:55PM
On 05/18/2018 10:36 AM, Peter Zijlstra wrote:
Replying to the latest version available; given the current interest I
figure I'd re-read some of the old threads and look at this stuff again.
On Fri, Apr 28, 2017 at 04:23:55PM +0200, Vincent Guittot wrote:
[...]
What happened to the proposed
On 05/18/2018 10:36 AM, Peter Zijlstra wrote:
Replying to the latest version available; given the current interest I
figure I'd re-read some of the old threads and look at this stuff again.
On Fri, Apr 28, 2017 at 04:23:55PM +0200, Vincent Guittot wrote:
[...]
What happened to the proposed
On Fri, May 18, 2018 at 02:08:51PM +0200, Peter Zijlstra wrote:
> However, I think we can shrink util_avg unconditionally, which would
> give us exactly the 4 byte hole we need.
There is of course the problem that we track rq util_avg as a straight
sum of entity util_avg, such that if you
On Fri, May 18, 2018 at 02:08:51PM +0200, Peter Zijlstra wrote:
> However, I think we can shrink util_avg unconditionally, which would
> give us exactly the 4 byte hole we need.
There is of course the problem that we track rq util_avg as a straight
sum of entity util_avg, such that if you
On Fri, May 18, 2018 at 11:17:38AM +0100, Patrick Bellasi wrote:
> On 18-May 11:36, Peter Zijlstra wrote:
> >
> > Replying to the latest version available; given the current interest I
> > figure I'd re-read some of the old threads and look at this stuff again.
> >
> > On Fri, Apr 28, 2017 at
On Fri, May 18, 2018 at 11:17:38AM +0100, Patrick Bellasi wrote:
> On 18-May 11:36, Peter Zijlstra wrote:
> >
> > Replying to the latest version available; given the current interest I
> > figure I'd re-read some of the old threads and look at this stuff again.
> >
> > On Fri, Apr 28, 2017 at
On 18-May 11:36, Peter Zijlstra wrote:
>
> Replying to the latest version available; given the current interest I
> figure I'd re-read some of the old threads and look at this stuff again.
>
> On Fri, Apr 28, 2017 at 04:23:55PM +0200, Vincent Guittot wrote:
>
> > diff --git
On 18-May 11:36, Peter Zijlstra wrote:
>
> Replying to the latest version available; given the current interest I
> figure I'd re-read some of the old threads and look at this stuff again.
>
> On Fri, Apr 28, 2017 at 04:23:55PM +0200, Vincent Guittot wrote:
>
> > diff --git
Replying to the latest version available; given the current interest I
figure I'd re-read some of the old threads and look at this stuff again.
On Fri, Apr 28, 2017 at 04:23:55PM +0200, Vincent Guittot wrote:
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 0978fb7..f8dde36
Replying to the latest version available; given the current interest I
figure I'd re-read some of the old threads and look at this stuff again.
On Fri, Apr 28, 2017 at 04:23:55PM +0200, Vincent Guittot wrote:
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 0978fb7..f8dde36
The current implementation of load tracking invariance scales the
contribution with current frequency and uarch performance (only for
utilization) of the CPU. One main result of this formula is that the
figures are capped by current capacity of CPU. Another one is that the
load_avg is not
The current implementation of load tracking invariance scales the
contribution with current frequency and uarch performance (only for
utilization) of the CPU. One main result of this formula is that the
figures are capped by current capacity of CPU. Another one is that the
load_avg is not
14 matches
Mail list logo