Message-ID: <20090530150438.GB11337@alecto.austad.us>
Date:	Sat, 30 May 2009 17:04:38 +0200
From:	Henrik Austad <henrik@...tad.us>
To:	GeunSik Lim <leemgs1@...il.com>
Cc:	finarfin@...amos.org, linux-kernel@...r.kernel.org
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@...tad.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists