If you want to check CPU load, you can have a look at the uptime command.
Let me show you before moving on.
So here we can see the uptime.
And in the uptime, you see three different parameters for the load average.
That's what we are going to talk about.
So this load average is the average of runnable processes over the last 1, 5, and 15 minutes.
So all of these are processes that need attention.
And as a rough guideline, this number should not exceed the number of CPU cores on a system.
At any time, use LSCPU to check the number of CPU cores and to see if you are OK.
Let me show you the output.
So here we have LSCPU.
And there on the top, we can see CPUs 2.
So this is a system that has two CPU cores.
Apple Silicon is what is used in this virtual machine.
The thing is that you can have more than two processes simultaneously running.
Let me make a drawing to explain how scheduling is working in a Linux environment.
So let's explore how process scheduling is running.
So you have some task.
And if you have some task, it is placed in the run queue, which is a part of the Linux kernel.
And in this run queue, you have all your tasks that need attention.
Now, the result of the run queue is you have different PIDs that are waiting in the run queue to be serviced.
And the run queue itself is handled by the scheduler.
And the scheduler is going to place these PIDs on a CPU for a specific time.
So CPU 0, CPU 1, CPU 2, CPU 3, that is how it is going to be working.
Now, every process is getting its time slice.
Once the process is preempted, that means that it is done in its current time slice,
the procedure repeats again, and the task is entering the run queue.
So let's explore the scheduler.
How is the scheduler working?
Well, the scheduler is a critical kernel component that makes sure that your CPUs are being serviced.
Let's say we have a two-CPU system, CPU 0 and CPU 1.
And then you have different processes that require attention.
Let's say P1, P2, P3, P4, and so on.
And what is going to happen if they all need to be serviced at the same time?
Well, this is why the scheduler is running in queue.
And every process that needs attention is getting in the run queue.
And it will be sorted there by order.
All these processes are getting a time slice in the run queue,
and these time slices are being serviced by the scheduler.
And at the moment that the scheduler is servicing a certain request,
at that moment, it will run it on a certain CPU,
which leaves the option that the next time you run the same process,
it might be running on a different CPU.
Now, the next thing that is happening is that every process is getting a certain amount of time,
and then it is getting preempted.
So that means that if it still needs to have some run time,
it needs to leave the CPU and enter the queue again.
And as I mentioned, next time it might be scheduled here,
and then it will be preempted again.
And that is going on all the time until the process is done.