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:4.227 / U:0.088 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site