Even though some of your points are quite interesting, to me the real question
is whether the RT subsystem should decide a policy or provide a capability. From
what I see, some think that rt-mem-management is a bad policy, whereas others
think that rt-mem-management is a very interesting capability.
Given the applications of RT systems and the underlying responsibilities of
their designers, both legal and moral, the system designers better know what
they are doing. This we will surely agree on. In that sense, there should be
very strict policies regarding possible behavior when designing and RT-based
system. That said, I'm not sure that limiting the capabilities of an RT system
designer will help make him/her a responsible human-being. Actually, it is likely
that if he/she feels limited, he/she will attempt to bypass/hack the current
capabilities to obtain the results he/she desires. In fact, chances are that
by providing a capability that has been designed and implemented by pros will
make RTL-systems safer since even though the designer might be inexperienced/
irresponsible, the system will know better.
To sum up, I assume we all are mature adults. Nobody needs to be told how
he/she should or should not design/program. Given the lead of an RTL-based system
that has rt-mem-management capability, I would very likely set a policy by which
rt-mem-management usage would require __Pontifical__ approval, but I'd nonetheless
appreciate the fact that it's available just in case ...
My 2 cents
David Olofson wrote:
> Well, I might have lost track somewhere, but if the pool is only available to
> RT tasks, and statically allocated, there is no resource balancing between RT
> and non RT - which would be one useful advantage if this could work. However,
> it cannot work, if the RT allocations are supposed to be hard RT.
>
> Anyway, even if the pool and allocator is RTL only, designing applications this
> way makes it a lot harder to figure out how much memory you really need not to
> ever run out of it. Then again, memory is rather cheap these days, and you can
> usually have lots of it if you need, even in embeded systems, so it might pay
> off if it simplifies the rest of the design to great extent...
>
> > Remember also that people seem to be thinking here in terms of a task
> > meeting its deadline with high precision every time. That is fine for
> > the highest priority task, but if you have many task, the lower priority
> > tasks will have significant jitter. Again, only a problem if you don't
> > take this into account in the design.
>
> Indeed, but the lower prio tasks (if any at all!) usually don't deal with that
> critical stuff - having the output data ready before the deadline is all that
> matters, since the actual timing is managed by the highest prio task, or in
> hardware. That is, jitter is not a big and complex problem in a correct design.
>
> Running out of memory OTOH, being forced to wait until some other task
> releases some, may well stall your task long enough to miss the deadline
> several times over. And if you have more than two or three tasks doing dynamic
> allocation, there's no realistic way of defining the worst case latency.
>
> David Olofson
> Programmer
> Reologica Instruments AB
> [EMAIL PROTECTED]
>
> ..- M u C o S --------------------------------. .- David Olofson ------.
> | A Free/Open Multimedia | | Audio Hacker |
> | Plugin and Integration Standard | | Linux Advocate |
> `------------> http://www.linuxdj.com/mucos -' | Open Source Advocate |
> ..- A u d i a l i t y ------------------------. | Singer |
> | Rock Solid Low Latency Signal Processing | | Songwriter |
> `---> http://www.angelfire.com/or/audiality -' `-> [EMAIL PROTECTED] -'
> -- [rtl] ---
> To unsubscribe:
> echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
> echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
> ---
> For more information on Real-Time Linux see:
> http://www.rtlinux.org/rtlinux/
--
===================================================
Karim Yaghmour
[EMAIL PROTECTED]
Operating System Consultant
(Linux kernel, real-time and distributed systems)
===================================================
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
