19

I am reading up on Linux processes from The Linux Documentation Project: https://www.tldp.org/LDP/tlk/kernel/processes.html

Processes are always making system calls and so may often need to wait. Even so, if a process executes until it waits then it still might use a disproportionate amount of CPU time and so Linux uses pre-emptive scheduling. In this scheme, each process is allowed to run for a small amount of time, 200ms, and, when this time has expired another process is selected to run and the original process is made to wait for a little while until it can run again. This small amount of time is known as a time-slice.

My question is, how is this time being kept track of? If the process is currently the only one occupying the CPU, then there is nothing actually checking if the time has expired, right?

I understand that processes jump to syscalls and those jump back to the scheduler, so it makes sense how processes can be “swapped” in that regards. But how is Linux capable of keeping track how much time a process has had on the CPU? Is it only possible via hardware timers?

Improve this question
1
  • 5
    A general note on TLDP: most of the documentation there was written in the late 1990s or early 2000s, and hasn't been updated since. Much of it's still valuable, but some parts are significantly out of date.
    – Mark
    Apr 20, 2020 at 23:06

1 Answer 1

Reset to default
25

The short answer is yes. All practical approaches to preemption will use some sort of CPU interrupt to jump back into privileged mode, i.e. the linux kernel scheduler.

If you look at your /proc/interrupts you'll find the interrupts used in the system, including timers.

Note that linux has several different types of schedulers, and the classic periodic timer style, is seldom used - from the Completely Fair Scheduler (CFS) documentation:

CFS uses nanosecond granularity accounting and does not rely on any jiffies or other HZ detail. Thus the CFS scheduler has no notion of “timeslices” in the way the previous scheduler had, and has no heuristics whatsoever.

Also, when a program issues a system call (Usually by a software interrupt - "trap"), the kernel is also able to preempt the calling program, this is especially evident with system calls waiting for data from other processes.

Improve this answer
4
  • 2
    Modern PCs typically use the HPET built into the chipset.
    – David Schwartz
    Apr 20, 2020 at 19:01
  • @DavidSchwartz I'm not much into x86 timers such as the HPET, but as far as I can see, TSC is chosen over HPET if it is stable. Also HPET is "slow" at typical 10-25MHz, and has many quirks registered in the kernel. My current setup is not receiving periodic interrupts from HPET at all, but did register it at boot time.
    – Henrik Juul Pedersen
    Apr 21, 2020 at 22:19
  • The TSC doesn't let you generate an interrupt when it reaches a particular value. So you can't use it for pre-emptive scheduling.
    – David Schwartz
    Apr 22, 2020 at 1:35
  • No, as I understand the x86 interrupts here, they are generated by the "APIC timer" as core local interrupts, on a basis of the TSC on my system. Neither HPET timer0 or timer1 is showing in the IRQ lists, so they're clearly not used, at least directly. As I read the code, linux will fall back to HPET, if it cannot find a better (stable) clock and interrupt source. Also, the question was whether linux needs an external trigger to perform preemption, and I believe my answer stands correct, regardless of the interrupt source (timer, software, keyboard..).
    – Henrik Juul Pedersen
    Apr 22, 2020 at 8:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.