Включается ли контекстный переключатель при прерывании?

Виртуальное адресное пространство процесса содержит 1 ГБ пространства ядра:

введите описание изображения здесь

Теперь я предполагаю, что это 1 ГБ пространства ядра указывает на данные и код, связанные с ядром (включая таблицу дескрипторов прерываний (IDT)).

Теперь предположим, что какой-то процесс выполняется ЦП, и этот процесс сделал системный вызов (уволил прерывание 0x80 (int 0x80 )). Что произойдет, так это то, что CPU перейдет в IDT и выполнит обработчик прерываний, связанный с номером прерывания 0x80 .

Теперь процессор останется в текущем процессе и выполнит обработчик прерываний из пространства ядра текущего процесса (так что не происходит переключения контекста)?

One Solution collect form web for “Включается ли контекстный переключатель при прерывании?”

int 0x80 предполагает i386; другие архитектуры могут использовать другие вещи, например syscall на amd64 . Если переключение контекста происходит каждый раз, когда выполняется системный вызов, это должно быть легко видимым, если мы запускаем программу, которая порождает глупо большое количество системных вызовов. К счастью, у меня есть такая программа.

 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" 

Когда мы скомпилируем это в 64-битной Linux-системе и запускаем ее под perf мы наблюдаем

 $ 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 $ 

всего лишь 88 переключателей контекста для этого процесса; если бы контекст переключался каждый раз, когда ядро ​​находилось в контексте процесса, мы должны были видеть где-то ближе к 9551615 контекстным переключателям.

Теперь! Если вы хотите, чтобы система зависала с помощью контекстных переключателей, запустите вышеуказанное под strace

 $ strace -c ./max ... 

А в другом окне vmstat 1 уже работает …

 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- rb 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 

Кажется довольно очевидным, когда strace и max (и другое программное обеспечение, если вы забыли /dev/null вывод), начали дико переключаться между ними.

  • Запустить скрипт при запуске для ядра Old Linux (3.0.0)
  • Как обновить CentOS 6.5 до ядра 2.6.32-431?
  • Как «раскодировать» сокет домена unix?
  • Загрузите ядро ​​Linux uboot на виртуальную машину
  • Инструмент для создания только встроенного исходного кода
  • Как ядро ​​Linux может обращаться к назначенному initramfs / initrd?
  • Содержимое Is / sys устарело в Linux?
  • Как применить патч ядра xenomai на debian?
  • Как запустить ядро ​​Linux?
  • sigaction (7): семантика члена si_code siginfo_t
  • Что такое «подрезы»?
  • Linux и Unix - лучшая ОС в мире.