Re: [PATCH] DRTL kernel 2.6.32-rc3 : SCHED_EDF, DI RT-Mutex, Deadline Based Interrupt Handlers

[Soumya K S]

On Thu, Oct 22, 2009 at 1:24 PM, Raistlin <raistlin@xxxxxxxx> wrote:
> On Wed, 2009-10-21 at 21:08 +0530, Soumya K S wrote:
>> Hello All,
>>
> Hi,
>
> I'm Dario, from Pisa (Italy), and I'm working on EDF scheduling for the
> Linux kernel as you do (don't know if you've seen the threads and the
> patches, all info here http://gitorious.org/sched_deadline/pages/Home).
>
Hi Dario, we needed a deadline based scheduler for DRTL and we zeroed
in upon SCHED_EDF. We see that the threads here are fairly new too :-P

>> The developed framework allows user to specify the real-time
>> strategies for a specific real-time scenario. User specifies
>> configurations like scheduling policy, Deadline-miss Fault-tolerance
>> limit, interrupt priorities, etc. Real-time applications use onetime
>> gateway to notify kernel that they require real-time response. All
>> applications use existing POSIX APIs. DRTL scheduler is time-aware and
>> uses EDF as the scheduling policy.
>>
> Nice, from here, it seemed we were working on very similar things, and I
> was wondering if we could somehow collaborate... :-)
>
Sure! That would be good :)

> Then I looked at the code and I saw our two designs are quite different,
> e.g., you don't constraint execution times, don't run any admission test
> to avoid oversubscription and you stop deadline missing tasks... Am I
> right?
> Even from the implementation point of view, I see you didn't used a new
> scheduling class.
>
A simple system where there a few real-time tasks and a few non-real
time tasks, the timelines can be architected out for each real-time
task in the system. In such a case, given the RT bandwidth in the
system, the task with the lowest deadline gets to be scheduled first
till it is there in the system.
In short, for such simple systems, we shifted the burden of admission
control to the architect and kept close to the existing code.

> However, I think there still would be room for collaboration, if you are
> interested in...
>
>> The patch consists of Time aware scheduler having SCHED_EDF as the
>> scheduling policy, Deadline based scheduling for Interrupt handlers,
>> Deadline Inheritance support for RT-Mutexes.
>>
> I was very curious on how you dealt with deadline inheritance in SMPs,
> than I saw this in your patch:
>
> diff -Naur linux-2.6.32-rc3/init/Kconfig linux-2.6.32-rc3-drtl/init/Kconfig
> +config SCHED_EDF
> +       bool "EDF Scheduler Support"
> +       default n
> +       depends on !GROUP_SCHED
> +       depends on !SMP
>
> :-P
>
> I'm right in the opposite situation, I've got SMP (partitioned for now,
> but we're working on migrations) and also CGROUPS support, but we are
> still wondering how deadline (or something more sophisticated, like
> bandwidth) inheritance could work in such a case...
>
That's right, we are still working on SMP and hope there are no
scalability issues in this patch w.r.t SMP.

> Again, I think I see collaboration possibilities, again, if you're
> interested in...
>
Definitely!

>> The patch is for the kernel version 2.6.32-rc3. It has been tested on
>> OMAP3530, ATMEL AT91SAM9261 and X86 platforms.
>>
> Ok... Are you also targeting (or plan to) preempt-rt kernels?
>
Yes, We do have the patches for preempt-rt kernel.

>> We look forward for support and feedback about
>> DRTL <http://docs.google.com/fileview?id=0BzLQtQ1qAO7uYjYyN2QwNGUtYWE2YS00MDc1LWExYWUtZTliNjNjNmZiZTZj&hl=en>
>> and the patch for its feasibility, scalability and performance.
>>
> Do you already have any numbers or testcase? I have some (well, a few!)
> of them... I'll try to find the time to give it a try to your patch with
> them...
>
We have tested Co-operative context switch time, Pre-emptive context
switch time and Interrupt Latency, all of them are of ~130us for
OMAP3530.

Regards,
Soumya
Shubhro
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/