On 17/12/13 18:03, bseg...@google.com wrote:
__synchronize_entity_decay will decay load_avg_contrib in order to
figure out how much to remove from old_cfs_rq->blocked_load.
update_entity_load_avg will update the underlying runnable_avg_sum/period that
is used to update load_avg_contrib.
(Normall
Chris Redpath writes:
> On 12/12/13 18:24, Peter Zijlstra wrote:
>> Would pre_schedule_idle() -> rq_last_tick_reset() -> rq->last_sched_tick
>> be useful?
>>
>> I suppose we could easily lift that to NO_HZ_COMMON.
>>
>
> Many thanks for the tip Peter, I have tried this out and it does provide
>
On Tue, Dec 17, 2013 at 02:09:13PM +, Chris Redpath wrote:
> On 12/12/13 18:24, Peter Zijlstra wrote:
> >Would pre_schedule_idle() -> rq_last_tick_reset() -> rq->last_sched_tick
> >be useful?
> >
> >I suppose we could easily lift that to NO_HZ_COMMON.
> >
>
> Many thanks for the tip Peter, I h
On 12/12/13 18:24, Peter Zijlstra wrote:
Would pre_schedule_idle() -> rq_last_tick_reset() -> rq->last_sched_tick
be useful?
I suppose we could easily lift that to NO_HZ_COMMON.
Many thanks for the tip Peter, I have tried this out and it does provide
enough information to be able to correct
On 12 December 2013 19:24, Peter Zijlstra wrote:
> On Tue, Dec 10, 2013 at 03:55:43PM +, Chris Redpath wrote:
>> >That's guestimating the last_runnable_update based on decay_count, and
>> >per the previous the decay count can get slightly out of sync.
>>
>> The guesstimation works fine, the is
On Tue, Dec 10, 2013 at 03:55:43PM +, Chris Redpath wrote:
> >That's guestimating the last_runnable_update based on decay_count, and
> >per the previous the decay count can get slightly out of sync.
>
> The guesstimation works fine, the issue is only that we can't tell at
> this point how much
On 10/12/13 15:14, Peter Zijlstra wrote:
On Tue, Dec 10, 2013 at 01:24:21PM +, Chris Redpath wrote:
What happens is that if you have a task which sleeps for a while and wakes
on a different CPU and the previous CPU hasn't had a tick for a while, then
that sleep time is lost.
/me more confu
On Tue, Dec 10, 2013 at 01:24:21PM +, Chris Redpath wrote:
> What happens is that if you have a task which sleeps for a while and wakes
> on a different CPU and the previous CPU hasn't had a tick for a while, then
> that sleep time is lost.
/me more confused now.
Where does update_cfs_rq_bloc
On 10/12/13 11:48, Peter Zijlstra wrote:
On Mon, Dec 09, 2013 at 12:59:10PM +, Chris Redpath wrote:
If we migrate a sleeping task away from a CPU which has the
tick stopped, then both the clock_task and decay_counter will
be out of date for that CPU and we will not decay load correctly
regar
On Mon, Dec 09, 2013 at 12:59:10PM +, Chris Redpath wrote:
> If we migrate a sleeping task away from a CPU which has the
> tick stopped, then both the clock_task and decay_counter will
> be out of date for that CPU and we will not decay load correctly
> regardless of how often we update the blo
Chris Redpath writes:
> If we migrate a sleeping task away from a CPU which has the
> tick stopped, then both the clock_task and decay_counter will
> be out of date for that CPU and we will not decay load correctly
> regardless of how often we update the blocked load.
>
> This is only an issue fo
11 matches
Mail list logo
