Linux - KernelThis forum is for all discussion relating to the Linux kernel.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
We are maintaining and developing a 1kHz control system for a robot. This system needs to be hard realtime. To achieve this, we are running our software under an RT-PREEMPT kernel.
However, I have heard that system calls are never realtime-safe in Linux -- in other words, there are no system calls guaranteed to never take a large amount of time. This doesn't make sense to me -- how could, say, clock_gettime() ever take a large amount of time if our thread has the highest realtime priority (and is the only thread at this priority)?
We are aware that many system calls -- such as networking, file IO, and malloc() -- generally aren't realtime safe. I am asking about the system calls that seem vital to basic operation of a program.
Are system calls ever realtime safe? If not, why?
Note: I have already asked this on StackOverflow, but have not gotten any satisfactorily confident or explanitory answers.
The Linux kernel does not guarantee that a process which is engaged in a system call will receive control within a specified time. It also does not guarantee that the fact that any process is engaged in a system call will not deprive some other process (or system activity) from being scheduled within a specified time.
Linux is not ... by design is not ... a RTOS.
I believe that you can either design a real-time operating system or a general-purpose one. These are fundamentally-conflicting design choices such that you cannot simultaneously, meaningfully have both.
Last edited by sundialsvcs; 07-18-2012 at 10:49 AM.
The Linux kernel does not guarantee that a process which is engaged in a system call will receive control within a specified time.
That is unfortunate. I guess we'll have to live with the knowledge that our system could possibly miss a deadline (fortunately, our system is resilient against the occasional missed deadline... but we'd prefer hard realtime) -- much of our system depends on Linux-only libraries and toolkits.
Quote:
It also does not guarantee that the fact that any process is engaged in a system call will not deprive some other process (or system activity) from being scheduled within a specified time.
I'm fairly sure that RT-PREEMPT, however, guarantees that a high-priority realtime task will preempt any lower-priority thread within some (unspecified but small) amount of time, regardless of that thread's execution state.
Quote:
Linux is not ... by design is not ... a RTOS.
I believe that you can either design a real-time operating system or a general-purpose one. These are fundamentally-conflicting design choices such that you cannot simultaneously, meaningfully have both.
I agree with this to an extent... but by changing some of those design choices it seems like RT-PREEMPT reverses most of the determinism-inhibiting effects of Linux's focus as a general-purpose OS.
Linux does have certain features which tilt toward the needs of "timing is really important" situations ... but please recognize that even these are sometimes pretty intrusive. When you start using features like RT-PREEMPT, other processes (upon which your task might also very much depend) can get starved.
Probably the best thing you can do is to equip your machine with the fastest CPU hardware you can afford, then make sure that the machine has nothing else to do with its time than to control your robot. Then, as you did, plan your setup to be resilient against the occasional missed deadline.
Linux does have certain features which tilt toward the needs of "timing is really important" situations ... but please recognize that even these are sometimes pretty intrusive. When you start using features like RT-PREEMPT, other processes (upon which your task might also very much depend) can get starved.
We're well aware of what we depend on (for this reason). Frankly, if our code approaches 100% processor usage, we'd prefer to starve other processes (even our own non-realtime tasks) before we miss a cycle.
Quote:
Probably the best thing you can do is to equip your machine with the fastest CPU hardware you can afford, then make sure that the machine has nothing else to do with its time than to control your robot. Then, as you did, plan your setup to be resilient against the occasional missed deadline.
We're actually using cpu groups to free up a core soley for our tasks. All other tasks go to another core on the system. In other words, we're already doing exactly what you're suggesting.
One thing I don't think I've asked as clearly as I should have is why?
Do you (or anyone else) have any idea why no system calls are realtime-safe?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.