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
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 mailto:amit.kucheria@linaro.org 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 linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
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 javascript: 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 javascript: http://lists.linaro.org/mailman/listinfo/linaro-dev
-- David Rusling CTO Linaro Ltd e. david....@linaro.org javascript: w. http://www.linaro.org Linaro: The future of Linux on ARM
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.holmes@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 http://retis.sssup.it/?q=node/35 [2] https://lkml.org/lkml/2013/2/**11/373https://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-devhttp://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
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 pmaccartee@mvista.comwrote:
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.holmes@linaro.orgwrote:
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/**35http://retis.sssup.it/?q=node/35 [2] https://lkml.org/lkml/2013/2/**11/373https://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-devhttp://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 pmaccartee@mvista.com
I believe before we merge these tress, we should do a good analysis and usecases for deadline scheduler? The networking issues are in dataplane where we want to reduce the latency and schedule dataplane thread ASAP. We also need to protect control plane at gross level, that probably can be done by reserving resources. We also need to do certain timer based processing, but most of these have big enough granularity that we can live without deadline scheduling.
I would like to hear the usecases before we merge the tree.
Pradeep
On 5/17/13 7:41 AM, Mark Orvek 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 <pmaccartee@mvista.com mailto:pmaccartee@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.holmes@linaro.org <mailto:mike.holmes@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... DaveAmit 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 <http://retis.sssup.it/?q=node/35> [2] https://lkml.org/lkml/2013/2/__11/373 <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 <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 <tel:408-572-7937> mobile: 415-637-0257 <tel:415-637-0257> pmaccartee@mvista.com <mailto:pmaccartee@mvista.com>-- Mark Orvek
mark.orvek@linaro.org mailto:mark.orvek@linaro.org
VP, Engineering
*M*: +1.408.313.6988*IRC:* morvek *Skype:* morvek linaro.org http://linaro.org │ Open source software for ARM SoCs
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.orvek@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 pmaccartee@mvista.comwrote:
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.holmes@linaro.orgwrote:
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/**35http://retis.sssup.it/?q=node/35 [2] https://lkml.org/lkml/2013/2/**11/373https://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-devhttp://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 pmaccartee@mvista.com
-- Mark Orvek
mark.orvek@linaro.org
VP, Engineering
*M*: +1.408.313.6988 *IRC:* morvek *Skype:* morvek linaro.org │ Open source software for ARM SoCs
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.kucheria@linaro.org] Sent: 19 May 2013 11:51 To: Mark Orvek Cc: Patrick MacCartee; Mike Holmes; linaro-networking; Lists linaro-dev; j.lelli@sssup.it; linaro-enterprise@linaro.org; lng-sc@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.orvek@linaro.orgmailto:mark.orvek@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 <pmaccartee@mvista.commailto:pmaccartee@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.holmes@linaro.orgmailto:mike.holmes@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.orgmailto:linar...@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
-- David Rusling CTO Linaro Ltd e. david....@linaro.orgmailto: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-7937tel:408-572-7937 mobile: 415-637-0257tel:415-637-0257 pmaccartee@mvista.commailto:pmaccartee@mvista.com
-- Mark Orvek
mark.orvek@linaro.orgmailto:mark.orvek@linaro.org
VP, Engineering
M: +1.408.313.6988 IRC: morvek Skype: morvek linaro.orghttp://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.
Hi,
On 05/20/2013 09:40 AM, Ola Liljedahl 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?
No, SCHED_DEADLINE isn't about reducing latency. That is instead the job of the PREEMPT_RT patchset. However, EDF scheduling is useful to control and reduce response time (and this can be seen as some sort of latency).
Best,
- Juri
-- Ola
*Ola Liljedahl, Networking System Architect, ARM*
*Telephone: +46 706 866 373 Skype: ola.liljedahl*
*From:*Amit Kucheria [mailto:amit.kucheria@linaro.org] *Sent:* 19 May 2013 11:51 *To:* Mark Orvek *Cc:* Patrick MacCartee; Mike Holmes; linaro-networking; Lists linaro-dev; j.lelli@sssup.it; linaro-enterprise@linaro.org; lng-sc@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.orvek@linaro.org mailto:mark.orvek@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 <pmaccartee@mvista.com mailto:pmaccartee@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.holmes@linaro.org mailto:mike.holmes@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 mailto:linar...@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
-- David Rusling CTO Linaro Ltd
e. david....@linaro.org mailto: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 tel:408-572-7937 mobile: 415-637-0257 tel:415-637-0257 pmaccartee@mvista.com mailto:pmaccartee@mvista.com
--
Mark Orvek
mark.orvek@linaro.org mailto:mark.orvek@linaro.org
VP, Engineering
*M*: +1.408.313.6988*IRC:* morvek *Skype:* morvek
linaro.org http://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.
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.Liljedahl@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.kucheria@linaro.org] Sent: 19 May 2013 11:51 To: Mark Orvek Cc: Patrick MacCartee; Mike Holmes; linaro-networking; Lists linaro-dev; j.lelli@sssup.it; linaro-enterprise@linaro.org; lng-sc@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.orvek@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 pmaccartee@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.holmes@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 pmaccartee@mvista.com
--
Mark Orvek
mark.orvek@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.
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?
-- Ola
Ola Liljedahl, Networking System Architect, ARM Telephone: +46 706 866 373 Skype: ola.liljedahl
-----Original Message----- From: Amit Kucheria [mailto:amit.kucheria@linaro.org] Sent: 20 May 2013 12:16 To: Ola Liljedahl Cc: Mark Orvek; Patrick MacCartee; Mike Holmes; linaro-networking; Lists linaro-dev; j.lelli@sssup.it; linaro-enterprise@linaro.org; lng-sc@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.Liljedahl@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.kucheria@linaro.org] Sent: 19 May 2013 11:51 To: Mark Orvek Cc: Patrick MacCartee; Mike Holmes; linaro-networking; Lists linaro-dev; j.lelli@sssup.it; linaro-enterprise@linaro.org; lng-sc@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.orvek@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 pmaccartee@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.holmes@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 pmaccartee@mvista.com
--
Mark Orvek
mark.orvek@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.
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.kucheria@linaro.org] Sent: 20 May 2013 12:16 To: Ola Liljedahl Cc: Mark Orvek; Patrick MacCartee; Mike Holmes; linaro-networking; Lists linaro-dev; j.lelli@sssup.it; linaro-enterprise@linaro.org; lng-sc@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.Liljedahl@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.kucheria@linaro.org] Sent: 19 May 2013 11:51 To: Mark Orvek Cc: Patrick MacCartee; Mike Holmes; linaro-networking; Lists linaro-dev; j.lelli@sssup.it; linaro-enterprise@linaro.org; lng-sc@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.orvek@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 pmaccartee@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.holmes@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 pmaccartee@mvista.com
--
Mark Orvek
mark.orvek@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.
Interesting. But SCHED_DEADLINE doesn't depend on the PREEMPT_RT modifications? Are these solutions overlapping in some areas?
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?
-- Ola
Ola Liljedahl, Networking System Architect, ARM Telephone: +46 706 866 373 Skype: ola.liljedahl
-----Original Message----- From: Juri Lelli [mailto:juri.lelli@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-enterprise@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.kucheria@linaro.org] Sent: 20 May 2013 12:16 To: Ola Liljedahl Cc: Mark Orvek; Patrick MacCartee; Mike Holmes; linaro-networking; Lists linaro-dev; j.lelli@sssup.it; linaro-enterprise@linaro.org; lng-sc@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.Liljedahl@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.kucheria@linaro.org] Sent: 19 May 2013 11:51 To: Mark Orvek Cc: Patrick MacCartee; Mike Holmes; linaro-networking; Lists linaro-dev; j.lelli@sssup.it; linaro-enterprise@linaro.org; lng-sc@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.orvek@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 pmaccartee@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.holmes@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 pmaccartee@mvista.com
--
Mark Orvek
mark.orvek@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.
Please refer to my earlier comment about Adaptive Tickless. I think you'll find it useful for the usecase you outlined below.
On Mon, May 20, 2013 at 6:07 PM, Ola Liljedahl Ola.Liljedahl@arm.com wrote:
Interesting. But SCHED_DEADLINE doesn't depend on the PREEMPT_RT modifications? Are these solutions overlapping in some areas?
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?
-- Ola
Ola Liljedahl, Networking System Architect, ARM Telephone: +46 706 866 373 Skype: ola.liljedahl
-----Original Message----- From: Juri Lelli [mailto:juri.lelli@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-enterprise@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.kucheria@linaro.org] Sent: 20 May 2013 12:16 To: Ola Liljedahl Cc: Mark Orvek; Patrick MacCartee; Mike Holmes; linaro-networking; Lists linaro-dev; j.lelli@sssup.it; linaro-enterprise@linaro.org; lng-sc@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.Liljedahl@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.kucheria@linaro.org] Sent: 19 May 2013 11:51 To: Mark Orvek Cc: Patrick MacCartee; Mike Holmes; linaro-networking; Lists linaro-dev; j.lelli@sssup.it; linaro-enterprise@linaro.org; lng-sc@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.orvek@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 pmaccartee@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.holmes@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 pmaccartee@mvista.com
--
Mark Orvek
mark.orvek@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.
Good article at LWN (well they are always good) referenced by the Linaro page you link to. The final comment is correct but not the complete answer. We also need determinism and no-interference for other reasons.
Adaptive tick-less should also be useful when you have multiple threads on the same core but are not using any type of time-sliced scheduling. Threads either wake up each other or are woken up by interrupts (could be the hrtimer with a thread-specific timeout).
-- Ola
Ola Liljedahl, Networking System Architect, ARM Telephone: +46 706 866 373 Skype: ola.liljedahl
-----Original Message----- From: Amit Kucheria [mailto:amit.kucheria@linaro.org] Sent: 20 May 2013 14:49 To: Ola Liljedahl Cc: Juri Lelli; Mark Orvek; Patrick MacCartee; Mike Holmes; linaro-networking; Lists linaro-dev; linaro-enterprise@linaro.org Subject: Re: Deadline scheduler inclusion in linux-linaro?
Please refer to my earlier comment about Adaptive Tickless. I think you'll find it useful for the usecase you outlined below.
On Mon, May 20, 2013 at 6:07 PM, Ola Liljedahl Ola.Liljedahl@arm.com wrote:
Interesting. But SCHED_DEADLINE doesn't depend on the PREEMPT_RT modifications? Are these solutions overlapping in some areas?
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?
-- Ola
Ola Liljedahl, Networking System Architect, ARM Telephone: +46 706 866 373 Skype: ola.liljedahl
-----Original Message----- From: Juri Lelli [mailto:juri.lelli@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-enterprise@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.kucheria@linaro.org] Sent: 20 May 2013 12:16 To: Ola Liljedahl Cc: Mark Orvek; Patrick MacCartee; Mike Holmes; linaro-networking; Lists linaro-dev; j.lelli@sssup.it; linaro-enterprise@linaro.org; lng-sc@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.Liljedahl@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.kucheria@linaro.org] Sent: 19 May 2013 11:51 To: Mark Orvek Cc: Patrick MacCartee; Mike Holmes; linaro-networking; Lists linaro-dev; j.lelli@sssup.it; linaro-enterprise@linaro.org; lng-sc@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.orvek@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 pmaccartee@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.holmes@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 pmaccartee@mvista.com
--
Mark Orvek
mark.orvek@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.
-- 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.
Hi,
Good progress that the adaptive tickless (CONFIG_NO_HZ_FULL) feature have made it to the kernel 3.10. But there's still work to be done, since (according to the LWN article) it is not fully tickless even when there's only one thread on a core. If kernel is still running a 1 HZ tick, it saves cycles but does not improve real-time properties of the system. The worst case response time of a core is still limited to the longest kernel maintenance task it may end up running during a tick (is there an upper limit?). Also throughput will suffer from one or more cores running maintenance and not processing packets. It adds jitter and makes it harder to guarantee maximum throughput figures.
Data plane cores would need to pile up maintenance work and process it only when told so ( application calling yield or some system calls).
About the multithread support, there would be only one truely tickless thread per core. If there are others, time slicing is probably needed, at least as a backup (swap out data plane thread if it is not yielding).
- Petri
On 20 May 2013 22:38, Ola Liljedahl Ola.Liljedahl@arm.com wrote:
Good article at LWN (well they are always good) referenced by the Linaro page you link to. The final comment is correct but not the complete answer. We also need determinism and no-interference for other reasons.
Adaptive tick-less should also be useful when you have multiple threads on the same core but are not using any type of time-sliced scheduling. Threads either wake up each other or are woken up by interrupts (could be the hrtimer with a thread-specific timeout).
-- Ola
Ola Liljedahl, Networking System Architect, ARM Telephone: +46 706 866 373 Skype: ola.liljedahl
-----Original Message----- From: Amit Kucheria [mailto:amit.kucheria@linaro.org] Sent: 20 May 2013 14:49 To: Ola Liljedahl Cc: Juri Lelli; Mark Orvek; Patrick MacCartee; Mike Holmes; linaro-networking; Lists linaro-dev; linaro-enterprise@linaro.org Subject: Re: Deadline scheduler inclusion in linux-linaro?
Please refer to my earlier comment about Adaptive Tickless. I think you'll find it useful for the usecase you outlined below.
On Mon, May 20, 2013 at 6:07 PM, Ola Liljedahl Ola.Liljedahl@arm.com wrote:
Interesting. But SCHED_DEADLINE doesn't depend on the PREEMPT_RT
modifications? Are these solutions overlapping in some areas?
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?
-- Ola
Ola Liljedahl, Networking System Architect, ARM Telephone: +46 706 866 373 Skype: ola.liljedahl
-----Original Message----- From: Juri Lelli [mailto:juri.lelli@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-enterprise@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.kucheria@linaro.org] Sent: 20 May 2013 12:16 To: Ola Liljedahl Cc: Mark Orvek; Patrick MacCartee; Mike Holmes; linaro-networking; Lists linaro-dev; j.lelli@sssup.it; linaro-enterprise@linaro.org; lng-sc@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.Liljedahl@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.kucheria@linaro.org] Sent: 19 May 2013 11:51 To: Mark Orvek Cc: Patrick MacCartee; Mike Holmes; linaro-networking; Lists linaro-dev; j.lelli@sssup.it; linaro-enterprise@linaro.org; lng-sc@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.orvek@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 pmaccartee@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.holmes@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 pmaccartee@mvista.com
--
Mark Orvek
mark.orvek@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.
-- 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.
-- You received this message because you are subscribed to the Google Groups " linaro-networking@linaro.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to linaro-networking+unsubscribe@linaro.org. To post to this group, send email to linaro-networking@linaro.org.
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.lelli@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-enterprise@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.kucheria@linaro.org] Sent: 20 May 2013 12:16 To: Ola Liljedahl Cc: Mark Orvek; Patrick MacCartee; Mike Holmes; linaro-networking; Lists linaro-dev; j.lelli@sssup.it; linaro-enterprise@linaro.org; lng-sc@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.Liljedahl@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.kucheria@linaro.org] Sent: 19 May 2013 11:51 To: Mark Orvek Cc: Patrick MacCartee; Mike Holmes; linaro-networking; Lists linaro-dev; j.lelli@sssup.it; linaro-enterprise@linaro.org; lng-sc@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.orvek@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 pmaccartee@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.holmes@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 pmaccartee@mvista.com
--
Mark Orvek
mark.orvek@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.
On Mon, May 20, 2013 at 5:48 PM, Juri Lelli juri.lelli@gmail.com wrote:
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
Over and above what Juri explained, you probably want to keep an eye on the Adaptive Tickless work[1]. It allows cpu isolation so that only the designated task will run on the 'tickless' cores - no scheduling, no interrupts or timers. PMWG has been tracking for its cpu isolation properties and Kevin Hilman landed 32-bit ARM support for the underlying context tracking in 3.10 [2].
Regards, Amit
[1] https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc/AdaptiveTickless [2] 64-bit support still WIP
On 05/19/2013 11:51 AM, Amit Kucheria wrote:
Similarly, the SCHED_DEADLINE patches shouldn't affect default runtime scheduler behaviour unless a task uses the DEADLINE policy.
Right, SCHED_DEADLINE is only one more scheduling policy you can use (as SCHED_FIFO/RR). If you don't use it the scheduler isn't affected.
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?
I started maintaining the patchset working on an implementation based on PREEMPT_RT, then we switched back as the main goal was mainline inclusion (and we didn't have real needs to be based on PREEMPT_RT). Anyway, the intersection was pretty clean, only minor modifications were needed to run SCHED_DEADLINE on top of PREEMPT_RT.
Best,
- Juri
On Fri, May 17, 2013 at 8:11 PM, Mark Orvek <mark.orvek@linaro.org mailto:mark.orvek@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 <pmaccartee@mvista.com <mailto:pmaccartee@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.holmes@linaro.org <mailto:mike.holmes@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... DaveAmit 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 <http://retis.sssup.it/?q=node/35> [2] https://lkml.org/lkml/2013/2/__11/373 <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 <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 <tel:408-572-7937> mobile: 415-637-0257 <tel:415-637-0257> pmaccartee@mvista.com <mailto:pmaccartee@mvista.com> -- Mark Orvek mark.orvek@linaro.org <mailto:mark.orvek@linaro.org> VP, Engineering *M*: +1.408.313.6988*IRC:* morvek *Skype:* morvek linaro.org <http://linaro.org> │ Open source software for ARM SoCs
Hi,
On 05/17/2013 11:15 AM, Amit Kucheria wrote:
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.
I just finished rebasing the patchset on top of 3.10-rc2. You can clone the repo from git://github.com/jlelli/sched-deadline.git and checkout the sched-dl-for-linaro branch, if you want to test it.
The test application I'm using is called rt-app and you can get it from here: git://github.com/gbagnoli/rt-app.git
Any kind of feedback is welcome and appreciated.
Best,
- Juri
-
Amit Kucheria -
David Rusling -
Juri Lelli -
Juri Lelli -
Mark Orvek -
Mike Holmes -
Ola Liljedahl -
Patrick MacCartee -
Petri Savolainen -
Pradeep Kathail