From: Henrik Austad <henrik@austad.us>
To: GeunSik Lim <leemgs1@gmail.com>
Cc: finarfin@dreamos.org, linux-kernel@vger.kernel.org
Subject: Re: SCHED_EDF infos
Date: Sat, 30 May 2009 15:34:41 +0200 [thread overview]
Message-ID: <20090530133441.GA11337@alecto.austad.us> (raw)
In-Reply-To: <49b7c2350905300438n6195de93la53bee3a309f71d@mail.gmail.com>
On Sat, May 30, 2009 at 08:38:29PM +0900, GeunSik Lim wrote:
> On Fri, May 8, 2009 at 6:10 PM, Henrik Austad <henrik@austad.us> wrote:
> >> [..]
> >> I think so.
> >> How can we approach EDF implementation like Pfair as a generic solution
> >> for Multicore in Linux?
> >
> > I am working on an implementation now, and I hope to be able to release a
> > prototype by the end of next week. I think we can continue the discussion
> > then based on that.
> Hi Henrik,
Hi!
btw, that 'end of next week'.. *sigh*
> 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
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?
> 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.
At the moment, this is only for my own convenice, but I have tried to modify as
little of the existing code as possible to avoid merge conflicts etc. So, none
of the existing syscalls have been modified in any way.
I'm a bit unsure as to what your question actually is, perhaps you could
elaborate a bit about what you're concered about?
henrik
next prev parent reply other threads:[~2009-05-30 13:41 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-29 21:36 SCHED_EDF infos finarfin
2009-04-30 7:39 ` Henrik Austad
2009-05-08 2:35 ` GeunSik Lim
2009-05-08 9:10 ` Henrik Austad
2009-05-30 11:38 ` GeunSik Lim
2009-05-30 13:34 ` Henrik Austad [this message]
2009-05-30 14:46 ` GeunSik Lim
2009-05-30 15:04 ` Henrik Austad
2009-05-30 19:15 ` Peter Zijlstra
2009-05-30 20:40 ` Henrik Austad
2009-05-30 21:15 ` Peter Zijlstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090530133441.GA11337@alecto.austad.us \
--to=henrik@austad.us \
--cc=finarfin@dreamos.org \
--cc=leemgs1@gmail.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox