The PREEMPT_RT patchset is configurable. I believe the default is PREEMPT_DESKTOP which is what most MV CGE customers use. Another config options is PREEMPT_NONE but I believe its usage is rare.
Mark On Fri, May 17, 2013 at 7:25 AM, Patrick MacCartee <pmaccar...@mvista.com>wrote: > Will these be added in a way that makes them easy to remove? Many, >95% > don't use Preempt RT in Linux as it impacts network performance and makes > things very temperamental. You would think people would just disable this > RT, but when trying to isolate issues it adds another variable to the mix. > I believe Yocto has a way of adding and removing RT patches that is some > what straight forward and preferable based on feedback from OEM's. > > Just a thought, > Patrick > > > On Fri, May 17, 2013 at 6:34 AM, Mike Holmes <mike.hol...@linaro.org>wrote: > >> In LNG you could end up with an interesting mix of preempt RT and >> deadline patches making the analysis and benchmarking interesting to >> interpret. >> In addition there are discussions about adding zero overhead linux (ZOL) >> like features. >> >> Mike >> >> >> >> On Friday, May 17, 2013 6:08:20 AM UTC-4, David Rusling wrote: >> >>> Amit, >>> an interesting proposal. I think that most of the LNG steering >>> committee is on this alias, but just in case, I'm adding them to it... >>> Dave >>> >>> Amit Kucheria >>> 17 May 2013 10:15 >>> Hi all, >>> >>> As part of our investigations into the Linux scheduler we've >>> interacted with Juri Lelli at the University of Pisa (cc'ed) who is >>> part of a group that is working on a DEADLINE scheduler[1] for >>> Linux[2]. >>> >>> While we're coming at this from a power managment angle[3], I suspect >>> that LEG and LNG already have real-world usecases that would benefit >>> from deadline scheduler found in other RTOSes. >>> >>> So I think it makes sense to merge Juri's tree into linux-linaro going >>> forward to allow easier experimentation. Does LEG and LNG have any >>> interest in this at this point? >>> >>> Juri has expressed an interest in maintaining a current branch of the >>> code that could be merged into our monthly release. In return, real >>> world usecases will improve his chances of getting the code merged >>> into mainline. >>> >>> Regards, >>> Amit >>> >>> [1] http://retis.sssup.it/?q=node/**35<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 > mobile: 415-637-0257 > pmaccar...@mvista.com > -- Mark Orvek mark.or...@linaro.org VP, Engineering *M*: +1.408.313.6988 *IRC:* morvek *Skype:* morvek linaro.org │ Open source software for ARM SoCs
_______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
