lkml.org 
[lkml]   [2010]   [Nov]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC][PATCH 07/22] sched: SCHED_DEADLINE push and pull logic
From
Date
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.



\
 
 \ /
  Last update: 2010-11-12 17:21    [W:0.449 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site