lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090530133441.GA11337@alecto.austad.us>
Date:	Sat, 30 May 2009 15:34:41 +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 08:38:29PM +0900, GeunSik Lim wrote:
> On Fri, May 8, 2009 at 6:10 PM, Henrik Austad <henrik@...tad.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
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ