Messages in this thread | | | Date | Thu, 5 Jun 2008 16:57:03 +0200 | From | Michael Trimarchi <> | Subject | Re: Inquiry: Should we remove "isolcpus= kernel boot option? (may have realtime uses) |
| |
> From: Peter Zijlstra <a.p.zijlstra@chello.nl> > Date: Thu, Jun 05, 2008 02:07:40PM +0200 > > On Thu, 2008-06-05 at 11:16 +0000, Michael Trimarchi wrote: ... > > 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. >
This is what I'm doing right now (apart from using timespec structs instead of u64 values to align the sched_param struct specified by POSIX on systems with SCHED_SPORADIC support).
I'll clean up the code and post it here in the next few days.
> 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. >
Ok, using the same mechanism even for SCHED_EDF tasks seems the right way to go.
> The only tricky bit here is PI :-) it would need to keep running despite > being over quota. >
There is some work in this area, and there are some protocols handling that, but that simple solution will be a good starting point.
| |