Re: Inquiry: Should we remove "isolcpus= kernel boot option? (may have realtime uses)

[Peter Zijlstra <a.p.zijlstra@chello.nl>]

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.

Exactly.

> > 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
expiring.

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.