| |||||||||||||
Why not just "cheat" and devote a whole core to the RT process?Why not just "cheat" and devote a whole core to the RT process?Posted Oct 20, 2012 18:52 UTC (Sat) by Richard_J_Neill (subscriber, #23093)Parent article: Software interrupts and realtime
On a multicore box, wouldn't it be easier just to dedicate a whole CPU core, 100% of the time to a particular process? In many of the RT use-cases I can think of, there's one task (often a single-threaded C-program) that needs to be able to run at top priority without interruption, while the entire rest of the OS, userspace and GUI could happily fit into the remaining cores.
Maybe I'm oversimplifying this, and it's certainly a bit wasteful (and won't work well for embedded), but for many common cases, such as low-latency audio processing, or avoiding dropouts, or data-acquistion, it would work just fine!
RT is hard when you have a mostly busy CPU (especially single-core), and multiple tasks, which might be relatively lightweight, require their small slice of CPU with hard-constraints on timing. But often, this isn't the case: we have just one critical task, and the system is mostly idle.
(Log in to post comments)
Why not just "cheat" and devote a whole core to the RT process? Posted Oct 20, 2012 19:09 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
because it's really rare that your real time processing only needs to do computation on data it already has. Usually you need to do other things besides computation (like I/O of the audio, disk, etc)
At that point you are interacting with the rest of the system and you need to worry about delays and locking in the rest of the kernel.
Why not just "cheat" and devote a whole core to the RT process? Posted Oct 29, 2012 18:20 UTC (Mon) by cbf123 (guest, #74020) [Link]
Intel's networking fastpath basically just throws power consumption out the window and dedicates entire cpu cores to spinning on the network devices.
100% cpu usage, constantly, but you get really low-latency networking!
A somewhat less intrusive method is to direct only the interrupts you care about to the "isolated" cpu while leaving all the rest to be handled as normal.
Why not just "cheat" and devote a whole core to the RT process? Posted Oct 31, 2012 19:32 UTC (Wed) by XTF (guest, #83255) [Link]
> On a multicore box, wouldn't it be easier just to dedicate a whole CPU core, 100% of the time to a particular process?
Doesn't this (kinda) happen automatically, if priorities are set right?
|
|||||||||||||