1

A process's virtual address space contains 1 GB of kernel space:

enter image description here

Now I assume that this 1 GB of kernel space points to data and code related to the kernel (including the Interrupt Descriptor Table (IDT)).

Now let's say that some process is being executed by the CPU, and this process made a system call (fired the interrupt 0x80 (int 0x80)). What will happen is that the CPU will go to the IDT and execute the interrupt handler associated with the interrupt number 0x80.

Now will the CPU stays in the current process, and execute the interrupt handler from the kernel space of the current process (so no context switching occurs)?

0

The int 0x80 assumes i386; other architectures might use other things e.g. syscall on amd64. If context switching happens every time a system call is made, that should be readily visible if we run a program that generates stupidly large numbers of system calls. Luckily, I have just such a program available.

bits 64

section .text

global _start

_start: mov r9,9551615
        mov rax,1       ; sys_write
        mov rdi,1       ; stdout
        mov rsi,letter
        mov rdx,1       ; length

_again: syscall
        dec r9
        jnz _again

        mov rax,60      ; sys_exit
        mov rdi,0       ; exit code
        syscall

section .data
letter: db "a"

When we compile this on a 64-bit linux system and run it under perf we observe

$ nasm -f elf64 -g -F dwarf -o max.o max.asm
$ ld -o max max.o
$ sudo perf stat ./max > /dev/null 2> perf.log
$ grep context perf.log
                88      context-switches          #    0.051 K/sec                  

$ 

merely 88 context switches for that process; if there were a context switch every time the kernel is in process context, we should have seen somewhere closer to 9551615 context switches.

Now! If you want to see the system flail around with context switches, run the above under strace

$ strace -c ./max
...

And in another window have vmstat 1 already running...

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0    896 333928   2132 3124628    0    0     0     0   74   98  0  0 100  0  0
 0  0    896 333896   2132 3124628    0    0     0     0   89  103  0  0 100  0  0
 0  0    896 333896   2132 3124628    0    0     0     0   65   85  0  0 100  0  0
 0  0    896 333896   2132 3124628    0    0     0     0   67   83  0  0 100  0  0
 2  0    896 333756   2132 3124628    0    0     0     0 21460 529902 10 29 61  0  0
 3  0    896 333832   2132 3124628    0    0     0     0 23690 652506 13 32 55  0  0
 1  0    896 333832   2132 3124628    0    0     0     0 27574 673152 11 33 55  0  0
 0  0    896 333768   2132 3124628    0    0     0     0 24351 650723 11 30 59  0  0

Seems pretty evident when strace and max (and other software, if you forgot to /dev/null the output) started wildly being switched between.

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.