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