John, Keeping the discussion theoretical, There are basically three ways to implement an RT Linux, one is as you said you change to the scheduler algorithm to give processes with "RT" priority the CPU when they need it. But this a only a kind of "soft RT system that works if your RT requirements are at the millisecond level
The second way is to run Linux itself as a low priority task on an RTOS. Actually you run a virtual machine as a low priority task on the RTOS and then Linux on the virtual machine. Then you implement things like queue and mailboxes and software interrupts and shared memory and more so the two types of processes can communicate. This is a full-on RTOS and will run at microsecond level The third method runs RT tasks inside a Linux device driver. This seems scary and it is. A null pointer can crash the system but it is easy to implement. This gives the RT task full access to the bare hardware Maybe there are more but those are what I've seen first hand. Garbage collection is a totally different thing. It can be an issue of not depending on how the programmer designs the software. Here we get into related areas like "safety" exact timing is different from a requirement to never crash. On Fri, Jun 22, 2018 at 7:45 PM John Dammeyer <jo...@autoartisans.com> wrote: > I'm pretty sure the Unix running on the PDP-10 that I used for a University > graphics course was also running a real time scheduler. And that was back > in 1982. > > What an RTOS does is provide a fair method of giving users equal time to > the > scarce resources. It does that at the cost of itself taking up CPU cycles > even if there isn't anyone else running. > > What an RTOS can also do is add priority to tasks so that some run at the > expense of others. There are all sorts of interesting ways of still giving > time to lower priority tasks over the higher ones. For example, each time > a > low priority task is not allowed to run, due to a ready to run higher > priority task, the lower one has it's priority incremented by one until it > can run. At that point it's lowered again to its original priority to > start the process all over again. > > That can have serious consequences for something like Linux which must be > ready to run at a precise interval with minimal or no jitter. You can't > suddenly have a lower priority task that's been waiting for a few seconds > to > then get a 20mS time slot. > > For the same reason, task that all have the same priority are scheduled in > a > round robin fashion which each getting equal time or less if they release > the processor while waiting for some sort of event. Badly written code > that spins in a loop will eat up it's entire 20ms slot when it really only > needs 100uS and then asks for a timer to wake it up again. That slows down > other task that perhaps need more time. > > I don't know how the regular Linux kernel handles things. As I recall, you > can assign priority to tasks. And an infinite loop program can still be > killed from another session so the low level OS doesn't really have any > problem dealing with the misbehaving code. > > So perhaps my understanding of a PREEMPT-RT is different from others. Is > it possible that with a standard Linux if you set up an infinite loop task > with the highest priority that you can no longer sign in via say the serial > port to kill that task? Normally a task with the same priority if it uses > round robin time slicing will still get access. So maybe the PREEMPT_RT is > priority based without round robin time slicing? > > Many of the newer programming languages use something called garbage > collection. Python is an example of that. It just asks for memory when > it > creates a variable. If the variable is changed to something else more > memory is requested. Eventually all this memory which can be a bit > fragmented is joined back together into one bigger chunk by the OS. That's > the garbage collection and can happen randomly from the perspective of the > operating program. > > Tasks that are created and disposed of say by the reception HTML WEB pages > also invoke the garbage collection. Once can't have that when trying to > read encoders or generate stepping pulses. > > So what does Linux do and what does PREMPT-RT do that's different. Maybe > someone can explain in simple elementary school level terms? > > Thanks > John > > > > -----Original Message----- > > From: Jon Elson [mailto:el...@pico-systems.com] > > Sent: June-22-18 6:43 PM > > To: Enhanced Machine Controller (EMC) > > Subject: Re: [Emc-users] Raspberry Pi PREEMPT-RT > > > > On 06/22/2018 11:10 AM, Peter C. Wallace wrote: > > > > > > > > > > > > Linux has had real time kernels for more than 10 years > > rt-linux was used by the original EMC (1) in about 1996 to > > port the original EMC over from Sun hardware. > > So, it has been about 22 years! Amazing! I got my first > > EMC system running in 1997, and was running a machine > > reliably with it by 1998. > > > > Jon > > > > > > ---------------------------------------------------------------------------- > -- > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > > Emc-users mailing list > > Emc-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > -- Chris Albertson Redondo Beach, California ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
