[lkml]   [2008]   [Jun]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Inquiry: Should we remove "isolcpus= kernel boot option? (may have realtime uses)
    On Thu, 2008-06-05 at 11:16 +0000, Michael Trimarchi wrote:
    > Hi,
    > > >
    > > > I'm working on a partitioned EDF scheduler right
    > > now, and I have to
    > > > face several issues, starting from the interface to
    > > use to expose the
    > > > EDF scheduler to userspace, and the integration with
    > > the existing
    > > > sched_rt policy.
    > >
    > > I would add a sched_class above sched_rt and let sched_rt
    > > run in all
    > > unclaimed time by sched_edf.
    > >
    > I add this type of class before sched_rt, so the next of sched_edf
    > point to sched_rt class.


    > > Have you looked at deadline inheritance to replace PI? I
    > > think it can be
    > > done reasonably simple by replacing the plist with a RB
    > > tree.
    > I think it can be done with an rb tree. The only tricky
    > part would be mixing tasks coming from the sched_edf and the sched_rt
    > class, but it should not be a problem.

    Mapping them onto U64_MAX - prio or something like that ought to do.

    Handling wraparound of the timeline might get a little involved though -
    then again realtime takes 584 yrs to wrap a 64bit ns counter.

    > > > By now I'm experimenting with an additional
    > > sched_class that implements
    > > > a SCHED_EDF policy, extending the POSIX struct
    > > sched_param with the
    > > > EDF parameters of the task, do you see any better way
    > > to do that?
    > > > Could that approach be reasonable?
    > >
    > > Yes, that is the way I'm leaning.
    > By now I'm facing some problems. I still have not clear what
    > parameters a task forked from a sched_edf task should get, as it would
    > involve some form of admission control,

    I'd start with something like:

    u64 sched_param::edf_period [ns]
    u64 sched_param::edf_runtime [ns]

    so that deadline = time_of_schedule + edf_period, and his allowance
    within that period is edf_runtime.

    fork would inherit the parent's settings, and we'd need to do admission
    control on all tasks entering SCHED_EDF, either through setscheduler()
    or fork(). We could fail with -ENOTIME or somesuch error.

    > and how to deal with tasks that run longer than their nominal
    > execution time (i.e., should we use some server mechanism to limit the
    > amount of cpu they're using, or handle that in some other way?)

    Yeah - we already account the amount of runtime, we can send them
    SIGXCPU and stop running them. Look at the rt_bandwidth code upstream -
    it basically stops rt task groups from running once their quota is
    depleted - waking them up once it gets refreshed due to the period

    For single tasks its easier, just account their time and dequeue them
    once it exceeds the quota, and enqueue them on a refresh timer thingy to
    start them again once the period rolls over.

    The only tricky bit here is PI :-) it would need to keep running despite
    being over quota.

     \ /
      Last update: 2008-06-05 14:11    [W:0.022 / U:1.540 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site