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

Groups > linux.kernel > #1309396 > unrolled thread

[RFC 5/8] Track the "total rq utilisation" too

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

  [RFC 5/8] Track the "total rq utilisation" too Luca Abeni <luca.abeni@unitn.it> - 2016-01-14 16:30 +0100
    Re: [RFC 5/8] Track the "total rq utilisation" too Peter Zijlstra <peterz@infradead.org> - 2016-01-14 20:20 +0100
      Re: [RFC 5/8] Track the "total rq utilisation" too Luca Abeni <luca.abeni@unitn.it> - 2016-01-15 09:10 +0100
    Re: [RFC 5/8] Track the "total rq utilisation" too Peter Zijlstra <peterz@infradead.org> - 2016-01-14 20:50 +0100
      Re: [RFC 5/8] Track the "total rq utilisation" too Luca Abeni <luca.abeni@unitn.it> - 2016-01-15 08:00 +0100
        Re: [RFC 5/8] Track the "total rq utilisation" too Peter Zijlstra <peterz@infradead.org> - 2016-01-15 09:40 +0100
          Re: [RFC 5/8] Track the "total rq utilisation" too Luca Abeni <luca.abeni@unitn.it> - 2016-01-15 10:20 +0100

#1309396 — [RFC 5/8] Track the "total rq utilisation" too

This is the sum of the utilisations of tasks that are assigned to
a runqueue, independently from their state (TASK_RUNNING or blocked)
---
 kernel/sched/deadline.c | 35 +++++++++++++++++++++++++++++++++--
 kernel/sched/sched.h    |  2 ++
 2 files changed, 35 insertions(+), 2 deletions(-)

diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index 0efa596..15d3fd8 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -52,6 +52,10 @@ static void add_running_bw(struct sched_dl_entity *dl_se, struct dl_rq *dl_rq)
 	lockdep_assert_held(&(rq_of_dl_rq(dl_rq))->lock);
 	dl_rq->running_bw += se_bw;
 	trace_sched_stat_running_bw_add(dl_task_of(dl_se), se_bw, dl_rq->running_bw);
+	if (dl_rq->running_bw > dl_rq->this_bw) {
+		WARN_ON(1);
+		dl_rq->running_bw = dl_rq->this_bw;
+	}
 }
 
 static void clear_running_bw(struct sched_dl_entity *dl_se, struct dl_rq *dl_rq)
@@ -67,6 +71,22 @@ static void clear_running_bw(struct sched_dl_entity *dl_se, struct dl_rq *dl_rq)
 	}
 }
 
+static void clear_rq_bw(struct sched_dl_entity *dl_se, struct dl_rq *dl_rq)
+{
+	u64 se_bw = dl_se->dl_bw;
+
+	dl_rq->this_bw -= se_bw;
+	WARN_ON(dl_rq->this_bw < 0);
+	if (dl_rq->this_bw < 0) dl_rq->this_bw = 0;
+}
+
+static void add_rq_bw(struct sched_dl_entity *dl_se, struct dl_rq *dl_rq)
+{
+	u64 se_bw = dl_se->dl_bw;
+
+	dl_rq->this_bw += se_bw;
+}
+
 static void task_go_inactive(struct task_struct *p)
 {
 	struct sched_dl_entity *dl_se = &p->dl;
@@ -104,6 +124,7 @@ static void task_go_inactive(struct task_struct *p)
 		clear_running_bw(dl_se, dl_rq);
 		if (!dl_task(p)) {
 			__dl_clear_params(p);
+			clear_rq_bw(&p->dl, &rq->dl);
 		}
 		return;
 	}
@@ -117,6 +138,7 @@ static void task_go_inactive(struct task_struct *p)
 		clear_running_bw(dl_se, dl_rq);
 		if (!dl_task(p)) {
 			__dl_clear_params(p);
+			clear_rq_bw(&p->dl, &rq->dl);
 		}
 	} else {
 		get_task_struct(p);
@@ -587,6 +609,7 @@ static void update_dl_entity(struct sched_dl_entity *dl_se,
 	 */
 	if (dl_se->dl_new) {
 		setup_new_dl_entity(dl_se, pi_se);
+		add_rq_bw(dl_se, dl_rq);
 		add_running_bw(dl_se, dl_rq);
 		return;
 	}
@@ -891,6 +914,7 @@ static enum hrtimer_restart inactive_task_timer(struct hrtimer *timer)
 	}
 	if (!dl_task(p)) {
 		__dl_clear_params(p);
+		clear_rq_bw(&p->dl, &rq->dl);
 
 		goto unlock;
 	}
@@ -1200,9 +1224,11 @@ select_task_rq_dl(struct task_struct *p, int cpu, int sd_flag, int flags)
 		if (hrtimer_active(&p->dl.inactive_timer)) {
 			raw_spin_lock(&rq->lock);
 			clear_running_bw(&p->dl, &rq->dl);
+			clear_rq_bw(&p->dl, &rq->dl);
 			raw_spin_unlock(&rq->lock);
 			rq = cpu_rq(cpu);
 			raw_spin_lock(&rq->lock);
+			add_rq_bw(&p->dl, &rq->dl);
 			add_running_bw(&p->dl, &rq->dl);
 			raw_spin_unlock(&rq->lock);
 		}
@@ -1664,7 +1690,9 @@ retry:
 
 	deactivate_task(rq, next_task, 0);
 	clear_running_bw(&next_task->dl, &rq->dl);
+	clear_rq_bw(&next_task->dl, &rq->dl);
 	set_task_cpu(next_task, later_rq->cpu);
+	add_rq_bw(&next_task->dl, &later_rq->dl);
 	add_running_bw(&next_task->dl, &later_rq->dl);
 	activate_task(later_rq, next_task, 0);
 	ret = 1;
@@ -1754,7 +1782,9 @@ static void pull_dl_task(struct rq *this_rq)
 
 			deactivate_task(src_rq, p, 0);
 			clear_running_bw(&p->dl, &src_rq->dl);
+			clear_rq_bw(&p->dl, &src_rq->dl);
 			set_task_cpu(p, this_cpu);
+			add_rq_bw(&p->dl, &this_rq->dl);
 			add_running_bw(&p->dl, &this_rq->dl);
 			activate_task(this_rq, p, 0);
 			dmin = p->dl.deadline;
@@ -1860,9 +1890,10 @@ static void switched_from_dl(struct rq *rq, struct task_struct *p)
 	 */
 	if (task_on_rq_queued(p))
 		task_go_inactive(p);
-	if (!hrtimer_active(&p->dl.inactive_timer))
+	if (!hrtimer_active(&p->dl.inactive_timer)) {
 		__dl_clear_params(p);
-	else if (!hrtimer_callback_running(&p->dl.inactive_timer))
+		clear_rq_bw(&p->dl, &rq->dl);
+	} else if (!hrtimer_callback_running(&p->dl.inactive_timer))
 		clear_running_bw(&p->dl, &rq->dl);
 
 	/*
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 9d0fdb1..d06005b 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -524,6 +524,8 @@ struct dl_rq {
 	 * and decreased when a task blocks
 	 */
 	s64 running_bw;
+
+	s64 this_bw;
 };
 
 #ifdef CONFIG_SMP
-- 
1.9.1

[toc] | [next] | [standalone]

#1309585

On Thu, Jan 14, 2016 at 04:24:50PM +0100, Luca Abeni wrote:
> +	if (dl_rq->running_bw > dl_rq->this_bw) {
> +		WARN_ON(1);
> +		dl_rq->running_bw = dl_rq->this_bw;
> +	}

FWIW you can write this as:

	if (WARN_ON(dl_rq->running_bw > dl_rq->this_bw))
		dl_rq->running_bw = dl_rq->this_bw;

[toc] | [prev] | [next] | [standalone]

#1309934

On 01/14/2016 08:12 PM, Peter Zijlstra wrote:
> On Thu, Jan 14, 2016 at 04:24:50PM +0100, Luca Abeni wrote:
>> +	if (dl_rq->running_bw > dl_rq->this_bw) {
>> +		WARN_ON(1);
>> +		dl_rq->running_bw = dl_rq->this_bw;
>> +	}
>
> FWIW you can write this as:
>
> 	if (WARN_ON(dl_rq->running_bw > dl_rq->this_bw))
> 		dl_rq->running_bw = dl_rq->this_bw;
Ah, thanks! I did not know that WARN_ON() returns a value...
This looks much nicer, I am locally changing in this way.


			Thanks,
				Luca

[toc] | [prev] | [next] | [standalone]

#1309606

On Thu, Jan 14, 2016 at 04:24:50PM +0100, Luca Abeni wrote:
> This is the sum of the utilisations of tasks that are assigned to
> a runqueue, independently from their state (TASK_RUNNING or blocked)

Is it actually used?

[toc] | [prev] | [next] | [standalone]

#1309906

On Thu, 14 Jan 2016 20:48:37 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> On Thu, Jan 14, 2016 at 04:24:50PM +0100, Luca Abeni wrote:
> > This is the sum of the utilisations of tasks that are assigned to
> > a runqueue, independently from their state (TASK_RUNNING or blocked)
> 
> Is it actually used?
Not in this patchset...
It is a possible "cheap" (but less accurate) alternative to the
tracking introduced in patch 4. Or can be used in more advanced
implementations of multi-processor GRUB, but not in this patchset.

So, it can be removed from the patchset; I added it so that people can
see all the possible alternative utilization tracking strategies.


		Thanks,
			Luca

[toc] | [prev] | [next] | [standalone]

#1309956

On Fri, Jan 15, 2016 at 07:50:49AM +0100, Luca Abeni wrote:
> On Thu, 14 Jan 2016 20:48:37 +0100
> Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > On Thu, Jan 14, 2016 at 04:24:50PM +0100, Luca Abeni wrote:
> > > This is the sum of the utilisations of tasks that are assigned to
> > > a runqueue, independently from their state (TASK_RUNNING or blocked)
> > 
> > Is it actually used?
> Not in this patchset...
> It is a possible "cheap" (but less accurate) alternative to the
> tracking introduced in patch 4. Or can be used in more advanced
> implementations of multi-processor GRUB, but not in this patchset.
> 
> So, it can be removed from the patchset; I added it so that people can
> see all the possible alternative utilization tracking strategies.

OK, so that might've been useful text for the changelog. But given that,
maybe leave it out for now.

BTW, have you got a paper on smp grub?

[toc] | [prev] | [next] | [standalone]

#1309979

On Fri, 15 Jan 2016 09:34:00 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> On Fri, Jan 15, 2016 at 07:50:49AM +0100, Luca Abeni wrote:
> > On Thu, 14 Jan 2016 20:48:37 +0100
> > Peter Zijlstra <peterz@infradead.org> wrote:
> > 
> > > On Thu, Jan 14, 2016 at 04:24:50PM +0100, Luca Abeni wrote:
> > > > This is the sum of the utilisations of tasks that are assigned
> > > > to a runqueue, independently from their state (TASK_RUNNING or
> > > > blocked)
> > > 
> > > Is it actually used?
> > Not in this patchset...
> > It is a possible "cheap" (but less accurate) alternative to the
> > tracking introduced in patch 4. Or can be used in more advanced
> > implementations of multi-processor GRUB, but not in this patchset.
> > 
> > So, it can be removed from the patchset; I added it so that people
> > can see all the possible alternative utilization tracking
> > strategies.
> 
> OK, so that might've been useful text for the changelog. But given
> that, maybe leave it out for now.
> 
> BTW, have you got a paper on smp grub?
The one mentioned in the cover letter describes the implementation I
posted:
http://disi.unitn.it/~abeni/reclaiming/rtlws14-grub.pdf

There is also a newer paper, that will be published at ACM SAC 2016
(so, it is not available yet), but is based on this technical report:
http://arxiv.org/abs/1512.01984
This second paper describes some more complex algorithms (easily
implementable over this patchset) that are able to guarantee hard
schedulability for SCHED_DEADLINE tasks with reclaiming on SMP.



				Luca

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web