On 05/20/2013 02:37 PM, Ola Liljedahl wrote:
Interesting. But SCHED_DEADLINE doesn't depend on the PREEMPT_RT
modifications? Are these solutions overlapping in some areas?
SCHED_DEADLINE does not depend on PREEMPT_RT. However, these two
patchsets can coexist, and you'll have benefits from both.
For the relevant use cases, I don't know if strict CPU allocation (a
fraction of the total CPU cycles) is needed. Instead these apps (we
are talking legacy SW) are designed so that specific threads must
start to execute very quickly (within 5-10 microseconds with an
almost 100% guarantee, this is also a bound of the overhead of the
wakeup and scheduling operations) when some event occurs (timer or
possibly some other type of interrupt). The biggest problem to this
today in Linux is the kernel itself (e.g. interrupt disabling,
locks). How does SCHED_DEADLINE handle this?
SCHED_DEADLINE does not address that kind of latency (time between
wakeup and actual execution). As Amit suggested, in the case you
can dedicate a core to a single task, you may want to disable timers
and perform no scheduling at all. In the end it's a matter of a ratio:
do you have enough cores to dedicate to single activities?
If the answer is no, than with SCHED_DEADLINE you can let critical
tasks run also on the same core and prove your system to be always
in a safe condition (if you account for scheduling overheads).
Best,
- Juri
-----Original Message----- From: Juri Lelli
[mailto:juri.le...@gmail.com] Sent: 20 May 2013 14:19 To: Ola
Liljedahl Cc: Amit Kucheria; Mark Orvek; Patrick MacCartee; Mike
Holmes; linaro-networking; Lists linaro-dev;
linaro-enterpr...@linaro.org Subject: Re: Deadline scheduler
inclusion in linux-linaro?
On 05/20/2013 12:27 PM, Ola Liljedahl wrote:
Predictable response times for specific threads. In the use cases
I am aware of, these threads would probably belong to the same
process and run core-affine on a specific core where as few as
possible other (kernel and user) threads and interrupts etc would
also run. A number of cores would follow this real-time model while
other cores preferably would keep the original Linux scheduling
and characteristics (to avoid introducing unexpected behaviour).
What benefits does SCHED_DEADLINE give in addition to stuff in
PREEMPT_RT?
Predictable response times are what SCHED_DEADLINE is about.
With SCHED_DEADLINE you can provide temporal guarantees up to 100%
CPU utilization that are not possibile with default real-time
policies (e.g. SCHED_FIFO/RR). This comes from the fact that
SCHED_DEADLINE achieves strong temporal isolation between tasks. You
can reserve a fraction of CPU time to your activities and be assured
that no one else can interfere with them. And this is critical also
in a low loaded system, if you want to be really safe against
unexpected interferences.
Basically, with SCHED_DEADLINE you can make a feasibility study (no
deadline will be missed) of the system under development beforehand,
and be sure, at run-time, that the timing requirements will be met
under any circumstance. You can't do the same using only stuff
already in PREEMPT_RT.
Best,
- Juri
-- Ola
Ola Liljedahl, Networking System Architect, ARM Telephone: +46 706
866 373 Skype: ola.liljedahl
-----Original Message----- From: Amit Kucheria
[mailto:amit.kuche...@linaro.org] Sent: 20 May 2013 12:16 To: Ola
Liljedahl Cc: Mark Orvek; Patrick MacCartee; Mike Holmes;
linaro-networking; Lists linaro-dev; j.le...@sssup.it;
linaro-enterpr...@linaro.org; lng...@linaro.org Subject: Re:
Deadline scheduler inclusion in linux-linaro?
Ola,
Are you concerned with lower system-wide scheduling latency or
with predictable response times for a particular task?
I believe SCHED_DEADLINE with help with the later.
/Amit
On Mon, May 20, 2013 at 1:10 PM, Ola Liljedahl
<ola.liljed...@arm.com> wrote:
In my experience, networking is moving away from realtime
scheduling (and thus RTOS’es). There are some lingering
requirements for some of the processing in the wireless stack
but the main difficulty here is getting the scheduling latency
down to acceptable levels, e.g. five microseconds or so. Will
SCHED_DEADLINE help here?
-- Ola
Ola Liljedahl, Networking System Architect, ARM
Telephone: +46 706 866 373 Skype: ola.liljedahl
From: Amit Kucheria [mailto:amit.kuche...@linaro.org] Sent: 19
May 2013 11:51 To: Mark Orvek Cc: Patrick MacCartee; Mike
Holmes; linaro-networking; Lists linaro-dev; j.le...@sssup.it;
linaro-enterpr...@linaro.org; lng...@linaro.org Subject: Re:
Deadline scheduler inclusion in linux-linaro?
Similarly, the SCHED_DEADLINE patches shouldn't affect default
runtime scheduler behaviour unless a task uses the DEADLINE
policy.
However, I haven't studied the intersection of the Preempt RT
and SCHED_DEADLINE patches in source form yet. If they touch
common pieces of code, merging both in might be an ongoing
effort. Juri, do you know?
On Fri, May 17, 2013 at 8:11 PM, Mark Orvek
<mark.or...@linaro.org> wrote:
The PREEMPT_RT patchset is configurable. I believe the default
is PREEMPT_DESKTOP which is what most MV CGE customers use.
Another config options is PREEMPT_NONE but I believe its usage is
rare.
Mark
On Fri, May 17, 2013 at 7:25 AM, Patrick MacCartee
<pmaccar...@mvista.com> wrote:
Will these be added in a way that makes them easy to remove?
Many,
95% don't use Preempt RT in Linux as it impacts network
performance and makes things very temperamental. You would
think people would just disable this RT, but when trying to
isolate issues it adds another variable to the mix. I believe
Yocto has a way of adding and removing RT patches that is some
what straight forward and preferable based on feedback from
OEM's.
Just a thought,
Patrick
On Fri, May 17, 2013 at 6:34 AM, Mike Holmes
<mike.hol...@linaro.org> wrote:
In LNG you could end up with an interesting mix of preempt RT
and deadline patches making the analysis and benchmarking
interesting to interpret. In addition there are discussions about
adding zero overhead linux (ZOL) like features.
Mike
On Friday, May 17, 2013 6:08:20 AM UTC-4, David Rusling wrote:
Amit, an interesting proposal. I think that most of the LNG
steering committee is on this alias, but just in case, I'm
adding them to it... Dave
Amit Kucheria
17 May 2013 10:15
Hi all,
As part of our investigations into the Linux scheduler we've
interacted with Juri Lelli at the University of Pisa (cc'ed) who
is part of a group that is working on a DEADLINE scheduler[1]
for Linux[2].
While we're coming at this from a power managment angle[3], I
suspect that LEG and LNG already have real-world usecases that
would benefit from deadline scheduler found in other RTOSes.
So I think it makes sense to merge Juri's tree into linux-linaro
going forward to allow easier experimentation. Does LEG and LNG
have any interest in this at this point?
Juri has expressed an interest in maintaining a current branch
of the code that could be merged into our monthly release. In
return, real world usecases will improve his chances of getting
the code merged into mainline.
Regards, Amit
[1] http://retis.sssup.it/?q=node/35 [2]
https://lkml.org/lkml/2013/2/11/373 [3] Mostly involving
discussions at this point, no real engineering effort invested
yet
_______________________________________________ linaro-dev
mailing list
linar...@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
-- David Rusling CTO Linaro Ltd
e. david....@linaro.org
w. http://www.linaro.org Linaro: The future of Linux on ARM
-- Patrick J. MacCartee Director of Product Management
MontaVista Software LLC fone: 408-572-7937 mobile: 415-637-0257
pmaccar...@mvista.com
--
Mark Orvek
mark.or...@linaro.org
VP, Engineering
M: +1.408.313.6988 IRC: morvek Skype: morvek
linaro.org │ Open source software for ARM SoCs
-- IMPORTANT NOTICE: The contents of this email and any
attachments are confidential and may also be privileged. If you
are not the intended recipient, please notify the sender
immediately and do not disclose the contents to any other person,
use it for any purpose, or store or copy the information in any
medium. Thank you.
-- IMPORTANT NOTICE: The contents of this email and any
attachments are confidential and may also be privileged. If you are
not the intended recipient, please notify the sender immediately
and do not disclose the contents to any other person, use it for
any purpose, or store or copy the information in any medium. Thank
you.
-- IMPORTANT NOTICE: The contents of this email and any attachments
are confidential and may also be privileged. If you are not the
intended recipient, please notify the sender immediately and do not
disclose the contents to any other person, use it for any purpose, or
store or copy the information in any medium. Thank you.
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
