public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: luca abeni <luca.abeni@unitn.it>
To: Peter Zijlstra <peterz@infradead.org>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	Juri Lelli <juri.lelli@arm.com>
Subject: Re: [RFC v2 4/7] Fix the update of the total -deadline utilization
Date: Tue, 5 Apr 2016 19:16:19 +0200	[thread overview]
Message-ID: <20160405191619.7d3f45d9@utopia> (raw)
In-Reply-To: <20160405125859.GY3430@twins.programming.kicks-ass.net>

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.

  reply	other threads:[~2016-04-05 17:16 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-01 15:12 [RFC v2 0/7] CPU reclaiming for SCHED_DEADLINE Luca Abeni
2016-04-01 15:12 ` [RFC v2 1/7] Track the active utilisation Luca Abeni
2016-04-05 12:23   ` Peter Zijlstra
2016-04-05 16:47     ` luca abeni
2016-04-01 15:12 ` [RFC v2 2/7] Correctly track the active utilisation for migrating tasks Luca Abeni
2016-04-05 12:24   ` Peter Zijlstra
2016-04-05 16:50     ` luca abeni
2016-04-01 15:12 ` [RFC v2 3/7] Improve the tracking of active utilisation Luca Abeni
2016-04-05 12:42   ` Peter Zijlstra
2016-04-05 17:00     ` luca abeni
2016-04-05 12:42   ` Peter Zijlstra
2016-04-05 17:05     ` luca abeni
2016-04-05 14:48   ` Peter Zijlstra
2016-04-05 17:17     ` luca abeni
2016-04-05 15:00   ` Peter Zijlstra
2016-04-05 17:56     ` luca abeni
2016-04-05 18:00       ` Peter Zijlstra
2016-04-05 19:35         ` luca abeni
2016-04-05 18:02       ` Peter Zijlstra
2016-04-05 19:24         ` luca abeni
2016-04-05 19:31           ` Peter Zijlstra
2016-04-05 19:32           ` luca abeni
2016-04-05 18:11       ` Peter Zijlstra
2016-04-01 15:12 ` [RFC v2 4/7] Fix the update of the total -deadline utilization Luca Abeni
2016-04-05 12:58   ` Peter Zijlstra
2016-04-05 17:16     ` luca abeni [this message]
2016-04-01 15:12 ` [RFC v2 5/7] GRUB accounting Luca Abeni
2016-04-01 15:12 ` [RFC v2 6/7] Make GRUB a task's flag Luca Abeni
2016-04-01 15:12 ` [RFC v2 7/7] Do not reclaim the whole CPU bandwidth Luca Abeni

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160405191619.7d3f45d9@utopia \
    --to=luca.abeni@unitn.it \
    --cc=juri.lelli@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox