From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id ACD5C360 for ; Wed, 14 Oct 2015 19:30:26 +0000 (UTC) Received: from seldrel01.sonyericsson.com (seldrel01.sonyericsson.com [37.139.156.2]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E0DA91ED for ; Wed, 14 Oct 2015 19:30:25 +0000 (UTC) To: References: <20151013124230.1a082d28@gandalf.local.home> <20151014092041.282117ac@gandalf.local.home> <20151014112225.26771952@gandalf.local.home> <20151014143244.19c2512a@gandalf.local.home> From: Tim Bird Message-ID: <561EAD4D.6080901@sonymobile.com> Date: Wed, 14 Oct 2015 12:30:21 -0700 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Subject: Re: [Ksummit-discuss] [TECH TOPIC] Mainlining PREEMPT_RT List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 10/14/2015 11:56 AM, Christoph Lameter wrote: > On Wed, 14 Oct 2015, Steven Rostedt wrote: > >> If PREEMPT_RT is not the way to go, then why did several companies just >> invest into getting it mainlined? > > I guess they want "realtime" support. Better talk to them what they mean > by realtime. I have never seen a real use case for PREEMPT_RT. Instead a > lot of high level "realtime" talk and disappointment when they found out > what the real constraints and limitations are. > >> Again, real-time does not mean real-fast. How do you handle priority >> inversion? How do you handle outliers? Which the Linux kernel has many >> huge outliers if things are not handled correctly, which PREEMPT_RT >> solve (making it, by the way, a hard real time design). If you can >> accept a single outlier, then that's soft real-time, and you are >> talking about something completely different. > > You could put the processing for the stuff that creates outliers on a > different cpu? Layout the processing in such a way to guarantee no > outliers on the "realtime" processors? > >> Hard real-time is about worse case latency, not the average latency. >> That's called "soft real-time" > > Of course. Thats why I suggested combining it with the NOHZ appraoch. Put > the pieces that can create outliers on cpus not used for "realtime" > threads. Ensure that what is running on a hard realtime cpu can complete > in a defined timed interval. > > Realtime is about guarantees of a response in a certain time period. That > is why "soft realtime" is not making much sense. There is no guarantee > anymore. Just more overhead. OS processing slows down due to the > sprinkling of preempt code but the timing guarantees that one seeks can be > violated. Increasing the processing overhead may increase the number of > failures to process a given task in a time period that one wants > guaranteed. So better run without preempt in order to have a higher chance > to finish in time? That is at least what my industry has decided to do. This debate is as old as the hills. I remember having it in 2000 with various parties, when talking about what used to be called the "dual-kernel" approach. > But we really wish we had a hard realtime capability if we must respond in > a certain time period. Sadly there is no solution in sight right now. Check out Xenomai. (xenomai.org) I think that's what many embedded folk use if they find that RT-PREEMPT does not meet their needs. Xenomai 3.0 allows you to use their system either on top of RT-PREEMPT or on top of their Cobalt kernel sitting next to (or in front of, depending on your perspective) the Linux kernel. Sony used RT-PREEMPT in some products, and a dual-kernel in others, and isolated CPUs running something else (usually uItron) in yet others. Personally, I'd be happy to see RT-PREEMPT go in - there are certain use cases for it. I'd also like to see the NOHZ stuff go in as well. It should solve a set of problems for isolating RT tasks without sacrificing performance on the non-RT CPUs. And finally, I wouldn't mind putting a non-Linux RT kernel like Cobalt (oh the horrors) into mainline as well. Each of these approaches has their strengths and weaknesses. Linux is, after all, whatever we say it is - and it could easily have a small RT micro-kernel as part of the source base as well. AFAIK the patent issues that plagued the dual-kernel approach are now behind us, so this might be a good area of investigation. I've long felt that RT-PREEMPT was sucking the oxygen out of getting other, technically valid, approaches to RT with Linux into mainline. -- Tim