Kernel itself: does the kernel stick to one processor core ?

Keruskerfuerst

Hello!

I have one question: does the kernel itself stick to one processor core ?
Normally one process should stick to one core (in a multicore processor) to to prevent cache and register saving to cache or RAM.

Christian99 · Veteran Joined: 28 May 2009 Posts: 1668

Your statement, that one process should stick to one core is a little bit oversimplified, I think.
Imagine, that one processor is fully loaded with a user process, that the user made sticking to the same core, that the kernel is stuck to, and this process has maximum priority (when talking about kernel/user processes, also processes started from root are user processes compared to kernel processes) the kernel would need to fight for ressources with this process, while other cores would be ideling.
That's not a good state IMHO.

I'm no expert on this, but I think, if you want to save cache and register saving, that core would be ONLY available to kernel. if kernel is paused to run a different process, the caches/registers need to be saved, too, no matter to what core the kernel is stuck.

And last, ther is no single kernel process AFAIK, but a multitude of them, so the kernel is able to take advantage of multiple cores itself.

Keruskerfuerst · Posted: Mon Sep 17, 2018 9:21 am Post subject:

Now, then: how does the kernel works itself ?
Does it support multicore processors (today only multicore processors are availaible) ?

Christian99 · Veteran Joined: 28 May 2009 Posts: 1668

Well the kernel does support multicore processors, otherwise it wouldn't be working on most modern computers

But I don't think, that's what you wanted to ask. what exactly do you mean/do you want to know?

NeddySeagoon · Posted: Mon Sep 17, 2018 11:05 am Post subject:

Keruskerfuerst,

The kernel manages user processes and kernel process in the same way.

The kernel has options to support various arrangements of Cores, CPUs and RAM.
If you only have a single core CPU, you can turn them all off.

Register saving/restoring on a process context switch is managed by the kernel.
Caches are not saved. They operate at the hardware level and the kernel is unaware of them.
They are a hardware 'trick' to make the RAM appear much faster that it really is.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

Keruskerfuerst · Posted: Mon Sep 17, 2018 3:08 pm Post subject:

Would it be better, if the kernel would work on one, single, reserved core
This would prevent the kernel itself from "jumping" to another core.
The modern CPUs have 8 cores and this means, that a single core would have 12,5% of the computing power of the hole CPU.
If I remember, about 10% of the computing power is normally needed for the kernel itself.

NeddySeagoon · Posted: Mon Sep 17, 2018 3:36 pm Post subject:

Keruskerfuerst,

That would rob the kernel of any opportunities for parallelism.

To put it another way, on an N core processor, when N-1 processes are waiting for the kernel on its exclusive core, N-1 cores are idle.
Maybe those N-1 cores could have been running kernel processes?

Its a faulty concept to think of the kernel as a separate entity.
Kernel processes are more privileged than user processes but there is only the totality of the process pool.

Some user processes are more unruly than others, being memory bound or compute bound or IO bound or whatever.
It makes sense to limit the resources that such processes can consume so that the system is still responsive.
The kernel is none of these things but it does provide the means to apply these limits to processes.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

Keruskerfuerst · Posted: Tue Sep 18, 2018 6:02 am Post subject:

What should I think of that ?

NeddySeagoon · Posted: Tue Sep 18, 2018 9:23 am Post subject:

Keruskerfuerst,

That its not a good idea to reserve one core for the kernel.

It is in general, a good idea to avoid context switches and the same process switching CPUs as these activities do not aid throughput.
Much like branch instructions is a program do not aid calculating the end result and can often be optimised away.

A context switch is saving the CPU (core) state for one process and restoring it for another.
There is no distinction between kernel processes and user processes here. Its all context switching.

Something similar has to be done for interrupts. However, its usually up to it interrupt handler to decide what it needs to save, so that it can be restored when it returns.
e.g. if the interrupt handler will not need the FPU, it need not save the FPU state.
Its given that when an interrupt handler returns it always returns to the process that was interrupted.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.