lkml.org 
[lkml]   [2009]   [May]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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/

    \
     
     \ /
      Last update: 2009-05-30 17:07    [W:2.305 / U:0.468 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site