Linked by Thom Holwerda on Sun 28th Feb 2010 23:54 UTC, submitted by cloud
Linux Evidence has just submitted to LKML a new version of the SCHED_DEADLINE real-time CPU scheduler for the Linux kernel. The project is basically a new scheduling policy (implemented inside its own scheduling class) aiming at introducing deadline scheduling for Linux tasks, and it is being developed by Evidence in the context of the EU-Funded project ACTORS. This version takes into account comments come from Linux kernel developers, and it also introduces a first drafted implementation of deadline inheritance.
Order by: Score:
Just what is needed
by strcpy on Mon 1st Mar 2010 11:48 UTC
strcpy
Member since:
2009-05-20

Just what Linux needs, yet another scheduler. Oh well.

Reply Score: 0

RE: Just what is needed
by silix on Mon 1st Mar 2010 13:53 UTC in reply to "Just what is needed"
silix Member since:
2006-03-01

Just what Linux needs, yet another scheduler. Oh well.


af far as i care they could well add not even one, but some hundred more scheduling classes, if at least one among them can let linux catch up with recent realtime OS reasearch - it's been years since i read publications about deadline monotonic scheduling for HARD realtime systems, and it wasn't "new" stuff even at the time...

hard realtime tasks don't just require timely activation and shortest schedule-in latencies - they need to be able to rely on system calls they invoke, taking deterministic times to execute - without this, they cannot guarantee temporally correct behaviour (which is the essence of real time computing), no matter the scheduling classes

so the point is, what does linux do to ensure that code paths for IO operations, enumeration of processes or files in a directory, or *whatever*, run in a constant, or at least upper bound, time?

Edited 2010-03-01 13:54 UTC

Reply Score: 5

RE[2]: Just what is needed
by Lennie on Mon 1st Mar 2010 21:51 UTC in reply to "RE: Just what is needed"
Lennie Member since:
2007-09-22

You do know that the realtime code in Linux main mostly comes in junks and pieces from existing real time Linux projects ? It's not like Linux not already does this, but it just takes time to make it more generic and suitable for general consumption.

Reply Score: 2

RE[3]: Just what is needed
by silix on Mon 1st Mar 2010 23:43 UTC in reply to "RE[2]: Just what is needed"
silix Member since:
2006-03-01

You do know that the realtime code in Linux main mostly comes in junks and pieces from existing real time Linux projects ?

yes, i know - but i'm not interested in a particular variant or branch or distribution, thus when i said "what does linux do to..." i actually meant "what is being done in the linux ecosystem to..."
i didnt make myself clear, my fault

It's not like Linux not already does this

so you'll be able to point me to paper in which the "syscall execution time" problem is analysed, and solutions are detailed, which is what i asked earlier :-)

but it just takes time to make it more generic and suitable for general consumption.

it would be nice to define "general consumption" -
in reality, hard real time is something that belongs to critical systems devoted to specific tasks for which a specific software solution is holistically tailored and deployed
that HRT is needed for MP3's and movies to play without stuttering is a common misconception - the most renowned multimedia prone desktop operating system (the BeOS) was not a real time OS, and many multimedia application are implemented as normal event loops (calculating delta's between the current and a previous timestamp to , e.g. calculate the frames needed for the animation to appear fluid, but not so much relying on system call nominal execution times)

desktop users don't actually need HRt, they don't need to be able to run tasks at higher priority than the kernel itself (which is what a soft real time kernel mostly does), they need what they need is responsiveness, and responsiveness can be achieved via other means, like prioritizing interactive tasks at the IO operation (not just scheduling) level, and /or optimising local IPC (that between applications and the graphic server, for instance) with more efficient mechanisms than sockets (LRPC or doors, that other Os's have had for years, but linux lacks, being born as a server OS) or even basic functionality like handoff scheduling (needed to shorten and make more deterministic ipc latency, and that linux AFAIK doesn't have yet)

Reply Score: 1

RE[4]: Just what is needed
by Lennie on Fri 5th Mar 2010 00:40 UTC in reply to "RE[3]: Just what is needed"
Lennie Member since:
2007-09-22

With general consumption I just mean, the people working on mainline don't mind maintaining it. It can be added to mainline and less code is needed for 'fringe' cases, like some kind of embedded devices.

Reply Score: 2