Re: [RFC][PATCH 07/22] sched: SCHED_DEADLINE push and pull logic

[Peter Zijlstra]

On Fri, 2010-10-29 at 08:32 +0200, Raistlin wrote:
> Add dynamic migrations to SCHED_DEADLINE, so that tasks can
> be moved among CPUs when necessary. It is also possible to bind a
> task to a (set of) CPU(s), thus restricting its capability of
> migrating, or forbidding migrations at all.
> 
> The very same approach used in sched_rt is utilised:
>  - -deadline tasks are kept into CPU-specific runqueues,
>  - -deadline tasks are migrated among runqueues to achieve the
>    following:
>     * on an M-CPU system the M earliest deadline ready tasks
>       are always running;
>     * affinity/cpusets settings of all the -deadline tasks is
>       always respected. 

I haven't fully digested the patch, I keep getting side-tracked and its
a large patch.. however, I thought we would only allow 2 affinities,
strict per-cpu and full root-domain?

Since there are no existing applications using this, this won't break
anything except maybe some expectations :-)

The advantage of restricting the sched_setaffinity() calls like this is
that we can make the schedulability tests saner.

Keep 2 per-cpu utilization counts, a hard-rt and a soft-rt, and ensure
the sum stays <= 1. Use the hard-rt one for the planned SF_HARD_RT flag,
use the soft-rt one for !SF_HARD_RT with nr_cpus_allowed == 1, and use
\Sum (1-h-s) over the root domain for nr_cpus_allowed != 1.

Once you start allowing masks in between its nearly impossible to
guarantee anything.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/