From: Peter Zijlstra <peterz@infradead.org>
To: Raistlin <raistlin@linux.it>
Cc: Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
Steven Rostedt <rostedt@goodmis.org>,
Chris Friesen <cfriesen@nortel.com>,
Frederic Weisbecker <fweisbec@gmail.com>,
Darren Hart <darren@dvhart.com>, Henrik Austad <henrik@austad.us>,
Johan Eker <johan.eker@ericsson.com>,
"p.faure" <p.faure@akatech.ch>,
linux-kernel <linux-kernel@vger.kernel.org>,
Claudio Scordino <claudio@evidence.eu.com>,
michael trimarchi <trimarchi@retis.sssup.it>,
Fabio Checconi <fabio@gandalf.sssup.it>,
Tommaso Cucinotta <t.cucinotta@sssup.it>,
Juri Lelli <juri.lelli@gmail.com>,
Nicola Manica <nicola.manica@gmail.com>,
Luca Abeni <luca.abeni@unitn.it>
Subject: Re: [RFC][PATCH 10/11] sched: add bandwidth management for sched_dl.
Date: Wed, 14 Apr 2010 12:09:48 +0200 [thread overview]
Message-ID: <1271239788.32749.15.camel@laptop> (raw)
In-Reply-To: <1267385230.13676.101.camel@Palantir>
On Sun, 2010-02-28 at 20:27 +0100, Raistlin wrote:
> @@ -2063,6 +2210,30 @@ task_hot(struct task_struct *p, u64 now, struct sched_domain *sd)
> return delta < (s64)sysctl_sched_migration_cost;
> }
>
> +/*
> + * When dealing with a -deadline task, we have to check if moving it to
> + * a new CPU is possible or not. In fact, this is only true iff there
> + * is enough bandwidth available on such CPU, otherwise we want the
> + * whole migration progedure to fail over.
> + */
> +static inline
> +bool __set_task_cpu_dl(struct task_struct *p, unsigned int cpu)
> +{
> + struct dl_bandwidth *dl_b = task_dl_bandwidth(p);
> +
> + raw_spin_lock(&dl_b->dl_runtime_lock);
> + if (dl_b->dl_bw < dl_b->dl_total_bw[cpu] + p->dl.dl_bw) {
> + raw_spin_unlock(&dl_b->dl_runtime_lock);
> +
> + return 0;
> + }
> + dl_b->dl_total_bw[task_cpu(p)] -= p->dl.dl_bw;
> + dl_b->dl_total_bw[cpu] += p->dl.dl_bw;
> + raw_spin_unlock(&dl_b->dl_runtime_lock);
> +
> + return 1;
> +}
> +
> void set_task_cpu(struct task_struct *p, unsigned int new_cpu)
> {
> #ifdef CONFIG_SCHED_DEBUG
> @@ -2077,6 +2248,9 @@ void set_task_cpu(struct task_struct *p, unsigned int new_cpu)
> trace_sched_migrate_task(p, new_cpu);
>
> if (task_cpu(p) != new_cpu) {
> + if (task_has_dl_policy(p) && !__set_task_cpu_dl(p, new_cpu))
> + return;
> +
> p->se.nr_migrations++;
> perf_sw_event(PERF_COUNT_SW_CPU_MIGRATIONS, 1, 1, NULL, 0);
> }
Yikes!!, I'm not sure we can sanely deal with set_task_cpu() doing that.
I'd much rather see us never attempting set_task_cpu() when we know its
not going to be possible.
That also means that things like set_cpus_allowed_ptr() /
sys_sched_setaffinity() will need to propagate the error back to their
users, which in turn will need to be able to cope.
next prev parent reply other threads:[~2010-04-15 7:29 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-28 19:06 [RFC][PATCH 0/11] sched: SCHED_DEADLINE v2 Raistlin
2010-02-28 19:15 ` [RFC][PATCH 01/11] sched: add sched_class->task_dead Raistlin
2010-02-28 19:17 ` [RFC][PATCH 02/11] sched: SCHED_DEADLINE policy implementation Raistlin
2010-04-13 18:22 ` Peter Zijlstra
2010-04-13 18:22 ` Peter Zijlstra
2010-04-13 18:22 ` Peter Zijlstra
2010-04-13 18:22 ` Peter Zijlstra
2010-04-13 18:55 ` Steven Rostedt
2010-04-15 7:34 ` Peter Zijlstra
2010-04-13 18:22 ` Peter Zijlstra
2010-02-28 19:18 ` [RFC][PATCH 03/11] sched: add extended scheduling interface Raistlin
2010-02-28 19:19 ` [RFC][PATCH 04/11] sched: add resource limits for -deadline tasks Raistlin
2010-02-28 19:20 ` [RFC][PATCH 05/11] sched: add a syscall to wait for the next instance Raistlin
2010-02-28 19:22 ` [RFC][PATCH 06/11] sched: add the sched-debug bits for sched_dl Raistlin
2010-02-28 19:23 ` [RFC][PATCH 07/11] sched: add latency tracing for -deadline tasks Raistlin
2010-02-28 19:24 ` [RFC][PATCH 08/11] sched: send SIGXCPU at -deadline task overruns Raistlin
2010-04-13 18:22 ` Peter Zijlstra
2010-04-13 19:32 ` Oleg Nesterov
2010-02-28 19:26 ` [RFC][PATCH 09/11] sched: first draft of deadline inheritance Raistlin
2010-04-14 8:25 ` Peter Zijlstra
2010-04-14 9:45 ` Peter Zijlstra
2010-02-28 19:27 ` [RFC][PATCH 10/11] sched: add bandwidth management for sched_dl Raistlin
2010-04-14 10:09 ` Peter Zijlstra [this message]
2010-02-28 19:28 ` [RFC][PATCH 11/11] sched: add sched_dl documentation Raistlin
2010-04-14 10:17 ` [RFC][PATCH 0/11] sched: SCHED_DEADLINE v2 Peter Zijlstra
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=1271239788.32749.15.camel@laptop \
--to=peterz@infradead.org \
--cc=cfriesen@nortel.com \
--cc=claudio@evidence.eu.com \
--cc=darren@dvhart.com \
--cc=fabio@gandalf.sssup.it \
--cc=fweisbec@gmail.com \
--cc=henrik@austad.us \
--cc=johan.eker@ericsson.com \
--cc=juri.lelli@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luca.abeni@unitn.it \
--cc=mingo@elte.hu \
--cc=nicola.manica@gmail.com \
--cc=p.faure@akatech.ch \
--cc=raistlin@linux.it \
--cc=rostedt@goodmis.org \
--cc=t.cucinotta@sssup.it \
--cc=tglx@linutronix.de \
--cc=trimarchi@retis.sssup.it \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.