Messages in this thread | | | Date | Sat, 30 May 2009 17:04:38 +0200 | From | Henrik Austad <> | Subject | Re: SCHED_EDF infos |
| |
On Sat, May 30, 2009 at 11:46:43PM +0900, GeunSik Lim wrote: > On Sat, May 30, 2009 at 10:34 PM, Henrik Austad <henrik@austad.us> wrote: > >> Can you share EDF that you implemented with P-fair for Multicore environments? > >> Especially, I wonder How do you keep posix compatibility with EDF scheduler. > > > > Well, what exactly do you mean by posix compatibility? What I'm doing, is adding
> This means that We can use realtime programming for EDF effectiveness with > current system call interface without new system call interface.
Well, as I said, at the moment I'm at the 'making it work'-stage, so adding features to the existing syscalls is not really something I'm prepared to do :-)
> > another scheduling class on top of sched_rt so that sched_pfair will be polled > > before any other class. I was not aware that POSIX had an EDF standard?
> POSIX describes common real-time specification without EDF, RMS , > Resource Reservation, etc. > Belows is the Linux Standard Base (LSB) specifications for Linux Distributions. > http://www.linuxfoundation.org/en/Specifications
Hoh, that was a lot of 'requried reading' :-s I'll try to have a look at it soon.
> >> For example, > >> sched_setscheduler(2), sched_getscheduler(2), > >> sched_get_priority_max(2), sched_get_priority_min(2), > >> sched_getaffinity(2), sched_setaffinity(2), > >> sched_getparam(2), sched_setparam(2), > >> setpriority(2), getpriority(2), > >> sched_yield(2), sched_rr_get_interval(2) > > > > I introduce 3 new syscalls for modifying the tasks. > > > > sched_pfair_update() > > - change an existing task into a pfair task, set attributes, calculate subjob > > values etc > > > > sched_pfair_release() > > - release the task, i.e. enable it to run on a CPU. > > > > sched_pfair_reweigh() > > - change the attributes of the task. In a lot of ways, this is very similar to > > pfair_update, but it introduces some problems when trying to reweigh a task > > that is running, or if the new values lead to over-utilization of the system.
> When we try to userspace realtime programming, How can we insert systemcall api > with posix compatibility.
At the moment, I've created a new sched-param struct:
struct sched_pfair_params { u64 period_ns; u64 wcet_ns; u64 deadline_ns; u64 release_ns; u8 periodic:1; };
so I can add this via a single variable to the syscalls.
> Um... In general, we use > sched_setscheduler (struct task_struct *p, int policy, struct > sched_param *param) api.
yes, I know, but I *really* didn't want to meddle with the exisint interface, so atm, I've just added my own syscalls.
> If we will make EDF related u/s rt programming, How do we have to > insert deadline of tasks > for EDF performance? > sched_setscheduler_EDF(struct task_struct *p, int policy, period-time > , runtime) > or > > struct sched_param { > int sched_priority; > <timespec edf-period-time>; > <timespec edf-runtiome>; > };
Could be, I guess this is up for debate. Having a dedicated structure for this is not good, but I hope my reason above can explain why it is like this at the moment.
henrik -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |