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
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 for tasks which are not on a runqueue
12 matches
Mail list logo
