Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1371545 > unrolled thread

Re: [RFC v2 4/7] Fix the update of the total -deadline utilization

Started byPeter Zijlstra <peterz@infradead.org>
First post2016-04-05 15:00 +0200
Last post2016-04-05 19:20 +0200
Articles 2 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [RFC v2 4/7] Fix the update of the total -deadline utilization Peter Zijlstra <peterz@infradead.org> - 2016-04-05 15:00 +0200
    Re: [RFC v2 4/7] Fix the update of the total -deadline utilization luca abeni <luca.abeni@unitn.it> - 2016-04-05 19:20 +0200

#1371545 — Re: [RFC v2 4/7] Fix the update of the total -deadline utilization

FromPeter Zijlstra <peterz@infradead.org>
Date2016-04-05 15:00 +0200
SubjectRe: [RFC v2 4/7] Fix the update of the total -deadline utilization
Message-ID<rkyKn-3D8-47@gated-at.bofh.it>
On Fri, Apr 01, 2016 at 05:12:30PM +0200, Luca Abeni wrote:
> +		/*
> +		 * XXX this is slightly incorrect: when the task
> +		 * utilization decreases, we should delay the total
> +		 * utilization change until the task's 0-lag point.
> +		 * But this would require to set the task's "inactive
> +		 * timer" when the task is not inactive.
> +		 */

Could you quickly remind me why this is a problem? The timeline does
continue running right? So even if the task isn't active now, it will
still reach its 0-lag point.

>  		__dl_clear(dl_b, p->dl.dl_bw);
>  		__dl_add(dl_b, new_bw);
>  		err = 0;

[toc] | [next] | [standalone]


#1371805

Fromluca abeni <luca.abeni@unitn.it>
Date2016-04-05 19:20 +0200
Message-ID<rkCNX-7ui-5@gated-at.bofh.it>
In reply to#1371545
Hi Peter,

On Tue, 5 Apr 2016 14:58:59 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Fri, Apr 01, 2016 at 05:12:30PM +0200, Luca Abeni wrote:
> > +		/*
> > +		 * XXX this is slightly incorrect: when the task
> > +		 * utilization decreases, we should delay the total
> > +		 * utilization change until the task's 0-lag point.
> > +		 * But this would require to set the task's "inactive
> > +		 * timer" when the task is not inactive.
> > +		 */
> 
> Could you quickly remind me why this is a problem?

Do you mean, why it is a problem to activate the "inactive timer"
when the task is inactive?
I designed inactive_task_timer() to be executed when the task is not
active (for example, if the task's state is TASK_RUNNING inactive_task_timer()
returns without doing anything).
One problem could be that inactive_task_timer() decreases the utilisation of
the task's rq (I am beginning to wonder if using the task's rq instead of the
rq of the CPU on which the timer is running is a good idea, BTW); if the task
is running, it can migrate to a different rq and inactive_task_timer() will
decrease the wrong utilisation.

Or do you mean why updating the utilisation now is a problem?
This is slightly incorrect because decreasing the utilisation too early we
risk to admit tasks that create a transient overload (with some unexpected
deadline misses).

Or did I misunderstand your question?



				Thanks,
					Luca

> The timeline does
> continue running right? So even if the task isn't active now, it will
> still reach its 0-lag point.

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web