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.kuche...@linaro.org] Sent: 20 May 2013 12:16 To: Ola Liljedahl Cc: Mark Orvek; Patrick MacCartee; Mike Holmes; linaro-networking; Lists linaro-dev; j.le...@sssup.it; linaro-enterpr...@linaro.org; lng...@linaro.org Subject: Re: Deadline scheduler inclusion in linux-linaro? Ola, Are you concerned with lower system-wide scheduling latency or with predictable response times for a particular task? I believe SCHED_DEADLINE with help with the later. /Amit On Mon, May 20, 2013 at 1:10 PM, Ola Liljedahl <ola.liljed...@arm.com> wrote: > In my experience, networking is moving away from realtime scheduling (and > thus RTOS’es). There are some lingering requirements for some of the > processing in the wireless stack but the main difficulty here is getting the > scheduling latency down to acceptable levels, e.g. five microseconds or so. > Will SCHED_DEADLINE help here? > > > > -- Ola > > > > Ola Liljedahl, Networking System Architect, ARM > > Telephone: +46 706 866 373 Skype: ola.liljedahl > > > > From: Amit Kucheria [mailto:amit.kuche...@linaro.org] > Sent: 19 May 2013 11:51 > To: Mark Orvek > Cc: Patrick MacCartee; Mike Holmes; linaro-networking; Lists linaro-dev; > j.le...@sssup.it; linaro-enterpr...@linaro.org; lng...@linaro.org > Subject: Re: Deadline scheduler inclusion in linux-linaro? > > > > Similarly, the SCHED_DEADLINE patches shouldn't affect default runtime > scheduler behaviour unless a task uses the DEADLINE policy. > > > > However, I haven't studied the intersection of the Preempt RT and > SCHED_DEADLINE patches in source form yet. If they touch common pieces of > code, merging both in might be an ongoing effort. Juri, do you know? > > > > On Fri, May 17, 2013 at 8:11 PM, Mark Orvek <mark.or...@linaro.org> wrote: > > The PREEMPT_RT patchset is configurable. I believe the default is > PREEMPT_DESKTOP which is what most MV CGE customers use. Another config > options is PREEMPT_NONE but I believe its usage is rare. > > > > Mark > > > > On Fri, May 17, 2013 at 7:25 AM, Patrick MacCartee <pmaccar...@mvista.com> > wrote: > > Will these be added in a way that makes them easy to remove? Many, >95% > don't use Preempt RT in Linux as it impacts network performance and makes > things very temperamental. You would think people would just disable this > RT, but when trying to isolate issues it adds another variable to the mix. I > believe Yocto has a way of adding and removing RT patches that is some what > straight forward and preferable based on feedback from OEM's. > > > > Just a thought, > > Patrick > > > > On Fri, May 17, 2013 at 6:34 AM, Mike Holmes <mike.hol...@linaro.org> wrote: > > In LNG you could end up with an interesting mix of preempt RT and deadline > patches making the analysis and benchmarking interesting to interpret. > In addition there are discussions about adding zero overhead linux (ZOL) > like features. > > Mike > > > > > On Friday, May 17, 2013 6:08:20 AM UTC-4, David Rusling wrote: > > Amit, > an interesting proposal. I think that most of the LNG steering > committee is on this alias, but just in case, I'm adding them to it... > Dave > > Amit Kucheria > > 17 May 2013 10:15 > > Hi all, > > As part of our investigations into the Linux scheduler we've > interacted with Juri Lelli at the University of Pisa (cc'ed) who is > part of a group that is working on a DEADLINE scheduler[1] for > Linux[2]. > > While we're coming at this from a power managment angle[3], I suspect > that LEG and LNG already have real-world usecases that would benefit > from deadline scheduler found in other RTOSes. > > So I think it makes sense to merge Juri's tree into linux-linaro going > forward to allow easier experimentation. Does LEG and LNG have any > interest in this at this point? > > Juri has expressed an interest in maintaining a current branch of the > code that could be merged into our monthly release. In return, real > world usecases will improve his chances of getting the code merged > into mainline. > > Regards, > Amit > > [1] http://retis.sssup.it/?q=node/35 > [2] https://lkml.org/lkml/2013/2/11/373 > [3] Mostly involving discussions at this point, no real engineering > effort invested yet > > _______________________________________________ > linaro-dev mailing list > > linar...@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > > > > -- > David Rusling > CTO > Linaro Ltd > > e. david....@linaro.org > > > w. http://www.linaro.org > Linaro: The future of Linux on ARM > > > > > > -- > Patrick J. MacCartee > Director of Product Management > MontaVista Software LLC > fone: 408-572-7937 > mobile: 415-637-0257 > pmaccar...@mvista.com > > > > > > -- > > Mark Orvek > > > > mark.or...@linaro.org > > > > VP, Engineering > > > > M: +1.408.313.6988 IRC: morvek Skype: morvek > > linaro.org │ Open source software for ARM SoCs > > > > > > > -- IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
