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