I'm currently reading Brian Wards book: How Linux Works: What Every Superuser Should Know 2nd edition and I'm confused about step 3 in the context of the other steps:
1. The CPU (the actual hardware) interrupts the current process based on an internal timer, switches into kernel mode, and hands control back to the kernel.

2. The kernel records the current state of the CPU and memory, which will be essential to resuming the process that was just interrupted.

3. The kernel performs any tasks that might have come up during the preceding time slice (such as collecting data from input and output, or I/O, operations).

4. The kernel is now ready to let another process run. The kernel analyzes the list of processes that are ready to run and chooses one.

5. The kernel prepares the memory for this new process, and then prepares the CPU.

6. The kernel tells the CPU how long the time slice for the new process will last.

7. The kernel switches the CPU into user mode and hands control of the CPU to the process.

What does he mean preceding time slice as surely the tasks have been completed during the time slice in steps 1-2?

The number of processes that can run in a single CPU at any given point of time is 1. For example if you have got a dual core processor which basically means you have got 2 CPUs on this system 2 processes can be processed by the CPU at any given point of time.

You will see many processes on the system but that doesn't mean that all of them are using the CPU at the same time only 1 or two processes (depending on the number of CPUs / cores you have) will be in running state and other will be either sleeping or waiting or in stopped state.

Whenever a process request for CPU it is kernel's responsibility to facilitate that. So kernel will set the time frame for how long process can use the CPU, how much memory is required etc. Once that time frame is over that process will be kicked out of the CPU but that doesn't mean that process completed all the tasks, it will again get in queue (depends on how heavily CPU is being used) if it need to perform more tasks.

Context switching basically means switching of processes / thread.

Hello T3RM1NVT0R,
But am I missing something: What is step 3 saying?

Here is the explanation:

If a process is already running in the CPU it get interrupted based on internal timer as they say, once that is done kernel gets the control back and is ready to fire a new request to the CPU. As they say kernel is the heart of the system any request to get to the physical hardware will be handled by the kernel. So when you type or even move your mouse you are interrupting any running process as the system has to immediately react to your request to type or move the cursor.

You might have noticed sometime that when you type the letters doesn't popup immediately it takes sometime to display on the screen, that is because CPU is busy processing other processes which cannot be interrupted immediately.

Again I will take the same example what I have taken for point 1. Suppose you have some application running in the background but suddenly you start moving your mouse or start typing then CPU has to give priority to that. Before it interrupts the running process it will save the stuff related to previous application in memory basically the state of CPU and memory which was when the process was actively running.

Here when it says preceding time slice we are talking about the time duration of the previous process, for example if previous process has requested for some I/O operation then kernel will finish it off, save the current state of CPU and memory for that process and then interrupt the process.

Steps 4-7 are pretty much self explanatory and is about the same cycle.

1 members found this post helpful.

I believe step 3 refers to kernel work that is either delayed from hardware interrupts or not driven by hardware interrupts, so it should occur at the end of a user time slice.

I don't know enough Linux kernel internals to know whether any actual work is managed that way.

Certainly some periodic kernel work can be triggered by the same clock as ended the time slice (rather than having its own hardware interrupt). But I would have expected that kind of thing to be less integrated with the context switching code than the above description implies.

Is there anyway to calculate what a theoretical maximum limit of (context switching/per second) for a CPU would be?

Yes and no. "No" being that different commands take different amounts of time for a CPU to complete different commands. I.E. a multiplication takes something like 8 clock ticks where an increment command takes a single clock tick. However "Yes" in the sense of there being a completely different way of thinking about it. Look at the commands "top" and "sar", specifically CPU load averages. Top and sar will show the virtual load average, which you divide by the number of CPU cores for the true load average. So a load of 0.5 on 2 CPU's would really be a true load of 0.25. So a true load of 1.0 would be that the CPU is running optimal performance, anything less then the CPU is relatively under worked, the system is rather idle. To be "By The Book" an administrator never wants to see a load over a 1.0, but I have seen systems run fairly smoothly even up to a 4.0. At an 8.0 you start seeing severe performance issues and might crash. On the other hand I have seen some really poorly managed systems run as high as a load of 32.0 and somehow it was still online and I was able to ssh into it. Granted it had taken about 10 minutes just for ssh to log in and another 15 minutes just for it to echo back that I had typed in reboot, but somehow it was still working and it actually responded to the reboot command after about another 20 minutes after it finally echoed back that I even typed in reboot. The joys of remote administration, but any case understanding load and true load of the system (CPU, I/O, DISK I/O all have load averages) is the more common defacto of how to think about the question you are asking.