3

Please comment on the following sentence:

On the standard Linux kernel without the rt patch, interrupts can't interrupt ongoing system calls. The reason why our machine doesn't stop working when data is fetched from the hard disk is because the system call we used for that operation is blocking. Blocking means that once it issues the request to the hard disc it changes the process state to blocked, and willingly gives up the processor time. There are no means to interrupt an ongoing system call on a non real time kernel.

This is my understanding of the topic, I am however, not sure if it is correct.

Improve this question

2 Answers 2

Reset to default
4

System calls can be interrupted through the use of signals, such as SIGINT (generated by CTRL+C), SIGHUP, etc. You can only interrupt them by interacting with the system calls through a PID, however when using Unix signals and the kill command.

rt_patch & system calls

@Alan asked the following follow-up question:

Is the possibility to interrupt system calls directly related with the acceptance of the rt_patch in the mainline Linux kernel?

My response:

I would think so. In researching this I couldn't find a smoking gun that says you could/couldn't do this which leads me to believe that you can.

The other data point which makes me think this, is that the underlying signals mechanism built into Unix is necessary for being able to interact with processes. I don't see how a system with these patches in place would be able to function without the ability to use signals.

Incidentally the signals operate at the process level. There isn't any method/API which I'm aware of for injecting interrupts to system calls directly.

References

Improve this answer
6
  • One part of the system calls is executed in kernels space. A found the following: However, Linux does not support the most demanding real-time applications because its kernel is nonpreemptive at the end of this chapter http://oreilly.com/catalog/linuxkernel/chapter/ch10.html#94726. Please comment on that
    – TheMeaningfulEngineer
    Jul 24, 2013 at 15:25
  • 4
    @Alan you should try to find a more recent book. That one covers kernel 2.2 and at the time 2.4 was coming out. It does not even mention the Completely Fair Scheduler that was introduced in an update of 2.6 and with the latest version 3 there are also big changes regarding preemptive processes under kernel space.
    – BitsOfNix
    Jul 24, 2013 at 15:43
  • @Alan - Alexandre is right. Get more current docs.
    – slm ♦
    Jul 24, 2013 at 15:54
  • This might be helpful: makelinux.net/kernel_map. Also there are a number of links to this Q&A I did for JoelDavis a couple of months ago that might be useful: unix.stackexchange.com/questions/76970/…
    – slm ♦
    Jul 24, 2013 at 16:02
  • Is the possibility to interrupt system calls directly related with the acceptance of the rt_patch in the mainline Linux kernel?
    – TheMeaningfulEngineer
    Jul 27, 2013 at 16:18
3

Of course interrupts can interrupt system calls, unless an appropriate spinlock is taken, or interrupts are disabled in some other way:

  • spin_lock_irq*() gets a spinlock and disables hardware interrupts (and, consequently, also software interrupt and tasklet processing).
  • spin_lock_bh() gets a spinlock and disables software interrupt and tasklet processing.
  • irq_disable() disables hardware interrupts.
  • local_bh_disable() disables software interrupt and tasklet processing.
  • preempt_disable() disables preemption, which is also disabled by any of the above.

Now, in non-preemptive kernels, tasks cannot preempt other tasks in kernel mode. So, if you have task A doing some heavy system call on your only CPU, and task B needs to write some data to the audio device, task B may need to wait for task A to end its system call, resulting in dropped audio causing an audible click. Preemptive kernels are for that case.

Improve this answer
2
  • Shouldn't the preemption of task A come from some form of an interrupt (say an interrupt which is signaling that the device task B has to write to is ready for accepting data) which could preempt the system call task A is undergoing? So it isn't task B which is interrupting directly.
    – TheMeaningfulEngineer
    Jul 25, 2013 at 11:42
  • Yes. The difference being that after returning from the interrupt, a reschedule may happen immediately, without waiting for the interrupted system call to finish.
    – ninjalj
    Jul 26, 2013 at 12:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .