Системные вызовы могут быть прерваны?

Строка "Мадам" free не показывает использование виртуальной памяти, оно показывает использование физической памяти.

"RES" (для резидентного объекта) и столбцы "%MEM" от top шоу Вы то же: физическая память, используемая каждым процессом.

free действительно показывает Вам доступную и используемую область подкачки, и top имеет его столбец "VIRT", оба из которых могут быть важными. Примерно, область подкачки плюс физическая память дает Вам Ваше общее возможное пространство виртуальной памяти. Доберитесь до того предела, и Вы начнете получать процессы, уничтоженные или не могущие выделить память, и вещи будут плохи.

2
24.07.2013, 18:04
2 ответа

Системные вызовы могут быть прерваны с помощью сигналов, такой как SIGINT (сгенерированный CTRL+C), SIGHUP, и т.д. Можно только прервать их путем взаимодействия с системными вызовами через PID, однако при использовании сигналов Unix и kill команда.

rt_patch и системные вызовы

@Alan задал следующий последующий вопрос:

Возможность состоит в том, чтобы прервать системные вызовы, непосредственно связанные с принятием rt_patch в магистрали ядро Linux?

Мой ответ:

Я думал бы так. В исследовании этого я не мог найти дымящееся оружие, которое говорит, что Вы могли сделать это, которое приводит меня полагать, что Вы можете.

Другая точка данных, которая заставляет меня думать это, то, что базовый механизм сигналов, встроенный в Unix, необходим для способности взаимодействовать с процессами. Я не вижу, как система с этими патчами на месте смогла бы функционировать без способности использовать сигналы.

Случайно сигналы работают на уровне процесса. Нет никакого метода/API, о котором я знаю для введения прерываний к системным вызовам непосредственно.

Ссылки

5
27.01.2020, 21:53
  • 1
    Одна часть системных вызовов выполняется в пространстве ядер. Найденный следующее: However, Linux does not support the most demanding real-time applications because its kernel is nonpreemptive в конце этой главы http://oreilly.com/catalog/linuxkernel/chapter/ch10.html#94726. Прокомментируйте тот –  TheMeaningfulEngineer 24.07.2013, 18:25
  • 2
    @Alan, необходимо попытаться найти более свежую книгу. Тот покрывает ядро 2.2 и в то время, когда 2.4 выходил. Это даже не упоминает Абсолютно Справедливый Планировщик, который был представлен в обновлении 2,6 и с последней версией 3 существуют также большие изменения относительно упреждающих процессов под пространством ядра. –  BitsOfNix 24.07.2013, 18:43
  • 3
    @Alan - Alexandre прав. Получите более актуальные документы. –  slm♦ 24.07.2013, 18:54
  • 4
    Это могло бы быть полезно: makelinux.net/kernel_map. Также существует много ссылок на это Вопросы и ответы, которые я сделал для JoelDavis несколько месяцев назад, который мог бы быть полезным: unix.stackexchange.com/questions/76970 / … –  slm♦ 24.07.2013, 19:02
  • 5
    , возможность прервать системные вызовы, непосредственно связанные с принятием rt_patch в магистрали ядро Linux? спасибо –  TheMeaningfulEngineer 27.07.2013, 19:18

Конечно, прерывания могут прервать системные вызовы, если соответствующая спин-блокировка не взята, или прерывания отключены некоторым другим способом:

  • spin_lock_irq*() получает спин-блокировку и отключает аппаратные прерывания (и, следовательно, также программное прерывание и tasklet, обрабатывающий).
  • spin_lock_bh() получает спин-блокировку и отключает обработка tasklet и программное прерывание.
  • irq_disable() отключает аппаратные прерывания.
  • local_bh_disable() отключает обработка tasklet и программное прерывание.
  • preempt_disable() отключает вытеснение, которое также отключено любым вышеупомянутым.

Теперь, в неприоритетных ядрах, задачи не могут вытеснить другие задачи в привилегированном режиме. Так, если у Вас есть задача выполнение некоторого тяжелого системного вызова на Вашем единственном ЦП, и задача B должна записать некоторые данные в аудиоустройство, задача B, возможно, должна ожидать задачи A закончить ее системный вызов, приводящий к отброшенному аудио, вызывающему слышимый щелчок. Приоритетные ядра для того случая.

2
27.01.2020, 21:53
  • 1
    не был Должен вытеснение задачи прибывший от некоторой формы прерывания (скажите, что прерывание, которое сигнализирует, что задача B устройства должна записать в, готово к принятию данных), который мог вытеснить задачу A системного вызова, подвергается? Таким образом, это не задача B, которая прерывает непосредственно. –  TheMeaningfulEngineer 25.07.2013, 14:42
  • 2
    Да. Причем различие - то, что после возврата из прерывания, переносить может сразу произойти, не ожидая прерванного системного вызова для окончания. –  ninjalj 26.07.2013, 15:14

Теги

Похожие вопросы