There is a similar question to mine here: https://stackoverflow.com/questions/43819072/does-the-kernel-stop-running-on-its-own-when-the-os-is-fully-loaded, but it has conflicting answers (so please do not mark this question as a duplicate).

Back to my question. I know that when the computer is powered on, the BIOS starts running, and the BIOS will run the boot loader, and the boot loader will run the kernel.

Now the kernel starts running as a normal program (by "normal program" I mean that the kernel is not just a group of functions that other programs calls, but rather it is also a program that runs on its own). Now the kernel will perform tasks such as:

  • Initializes hardware as well as kernel data structures.
  • Switch to protected mode.
  • Initialize Interrupt Descriptor Table.
  • etc. (this article lists a lot more tasks that the kernel does).

After the kernel finishes these tasks, the OS becomes loaded and the user can start using it.

My question is: now that the OS is loaded, does the kernel continue to run as a normal program, or will it stop running in this way and only run when an interrupt happens?


Any kernel is pretty much the complete opposite of a "normal program". Even though microkernel folks might like the idea of OS services running as processes in the same level as user application, the kernel is always going to have to include some part that's not. If nothing else, there must be some part of the OS that handles scheduling of and switching between the processes, and communication between them.

Particularly, on Linux, the kernel is mapped to the address space of all processes, in the upper part of the address space. In a sense, it's part of each process, in that some processes might be running kernel code while at the same time some other process might be running user-space code.

I wouldn't say the kernel runs as a normal program, but it also doesn't run "only" on interrupts, as user-space code can also call into kernel routines: that's what system calls are. Quotes around "only", since interrupts aren't at all exceptional, some sort of a regular timer tick is quite common to have.

  • "I wouldn't say the kernel runs as a normal program, but it also doesn't run "only" on interrupts, as user-space code can also call into kernel routines: that's what system calls are" But system calls are called through interrupts.
    – Joseph
    May 11 '17 at 15:56
  • 2
    @Joseph, yes, there's the old method of calling system calls via a software interrupt, but that's conceptually a bit different from a hardware interrupt. It's also not the only way to make system calls, there are also the SYSCALL and SYSENTER instructions, which I think are more modern.
    – ilkkachu
    May 11 '17 at 16:11

On a uniprocessing system, the processor can only run a single program at a time, so that either the OS or another program runs at a given time.

The os doesn't run as a normal program, as it is the entity in charge of scheduling the run of these programs. When a program runs, the OS doesn't do anything, and will be called back once an interrupt, a system call or a timeout happends. It can then either decide to work for itself, or run another program it is in charge of.

I don't understand why would the answer you're talking about be conflicting: some processes the OS run can be kernel componnents, having a higher level of privilege.

  • 1
    I guess a source of confusion can be kernel threads. Kernel threads are "housekeeping" routines that run wholly in the kernel memory space (i.e. they don't have user level memory pages and they don't cross the user-kernel border), but they are scheduled independently, just like user level threads . This means you could say the kernel is more than just an interrupt handler and a "big library" of functions that are called and returned from. You can see the kernel threads with ps aux: the processes enclosed in square brackets are kernel threads. May 11 '17 at 15:10
  • @Johan Myréen What do these kernel threads do? What does "housekeeping" means exactly?
    – Joseph
    May 11 '17 at 16:16
  • 2
    Write-behind flushing of dirty memory pages to disk, various asynchronous driver tasks (ie, stuff not handled synchronously in a syscall), rebalancing tasks across cores, lots of other stuff. If you know what the kernel does after boot (ie, what system facilities exist), it'll be easy to see which of them aren't just interrupt handlers and syscalls.
    – Useless
    May 11 '17 at 16:27
  • @Useless Does "rebalancing tasks across cores" means moving a thread that is running on some core to another core?
    – Joseph
    May 11 '17 at 16:32
  • @Joseph Yes it does
    – multun
    May 12 '17 at 7:26

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.