hi, Thu, May 08, 2025 at 16:11:35, alex wrote about "[uanog] Re: NIC interrupts / IRQs / Cores":
с 380 страницы - как раз про железо и обмены. и я особенно рекомендую с 393 страницы - "Точные и неточные прерывания". Очень хорошо описана проблематика простыми словами.
Описана, да. Но: 1) Неточные прерывания (imprecise interrupts/exceptions/etc.) в современных архитектурах не присутствуют. Ну, может, в самых маргинальных осталось. Аппаратные - вообще я не слышал, чтобы такое хоть где-то было, потому что это недопустимо, чтобы в непредсказуемые моменты тебе невосстановимо ломало всю работу. Было в некоторых (например, SPARC до какого-то момента) для _исключений_, вызванных программными событиями, типа неподдерживаемой команды, и то не всех (page fault, например, туда не входил). Начиная с середины 1990-х, точные прерывания у всех даже при самом сложном out-of-order. Да, цена за это - задержка между приходом запроса на прерывание и фактическим переходом к обработчику (может быть, условно, десятки тактов), часть команд завершаются, часть отбрасывается, граница между выполненными и отброшенными зависит от массы факторов и может меняться с каждой новой моделью. И вот это (с той же страницы)
поскольку после попытки деления на нуль перезапускать работавший процесс не имеет смысла.
Таненбаум неправ, оно может иметь смысл при самых разных ситуациях, юниксы генерируют сигнал, который может быть перехвачен, Windows через SEH позволяет ловить такие ситуации, в других ОС свои механизмы, но все позволяют адекватно перехватывать такое без фатальных последствий для процесса. Судя по тому, что в POWER точные исключения завезли в 1990, в x86 с момента его перехода в OoO (PentiumPro - 1996), а в S/370 ещё в 70-х - он отстал уже к моменту написания книги. 2) А какое это вообще имеет отношение к вопросу распределения прерываний по хартам/ядрам/процессорам/назови_как_хочешь? Там вопрос в том, чтобы сетевуха в принципе позволяла настраивать генерацию разных прерываний на разные ситуации, а дальше их раутинга по сети обработки, но сама обработка прерывания не меняется. Или вы про то, что вообще тема сложная?
Реально вы должны помнить: в современных компиляторах, вы программу пишете НЕ для железа а для "сферического процессора в акууме". Т.е. "программный код" не рассчитан на то что вот сейчас я его запущу именно с вот этогго адреса внутри памяти процессора :-) (я сейчас ОЧЕНЬ упрощаю...) Поэтому и наблюдается сейчас огромный отрыв в Программистах Старой Школы и тех кто начал писать уже с ООП и "джав". Старой школы уже отходят и умирают, а новой школы не появляется :-(
Так тем, кто пишет на верхних уровнях, это всё обычно и не нужно. Зато они другое умеют. Я вот например веб знаю на уровне HTML3.2 без CSS. А они знают и могут за час наклепать морду управления какой-то железякой с неплохим UI, им только надо сказать, за какие рычаги дёргать на стороне сервера - а я бы это неделю писал. Каждому тут своё.
Так вот, в мультипроцессорной системе, "железо" получается работает ТООЛЬКО через некую прокладку - т.е. ОС или "типа прокладок-драйверов", и вы, как Программист, постоянно оказываетесь в дурацкой ситуации: вы вроде как вынуждены применять некие функции (вызов функции) с передачей параметров, но в то же время вы полностью оторваны от "железных=аппаратных прерываний". ОС вам подсовывает некий "эрзац" который не всегда понятно как отрабатывать... (я сейчас ОЧЕНЬ упрощаю очень сложные процессы...)
А что, просто на уровне ОС это уже не был эрзац? Top half (hardinterrupt), bottom half (softinterrupt), состояние драйвера, wakeup в обработчике, sleep в process land, пока вышел, пока проверил, что нет сигналов процесса, пока шедулер разрешил исполняться...
Все еще усугубляется современным "модным течением" по "низкоуровнему программингу на Питоне". Поубивал-бы... :-( это приводит к тому, что Программисты вообще не понимают "как оно там внутри на низком уровне". Это печально, и это уже привело к "программированию для сферического коня в вакууме".
Что именно надо понимать, если задача выглядит в виде "при условии функция need_buka поставить высокий уровень на выходную ногу 12", когда эта need_buka видит, например, команду оператора "дави его!", а от того питона там клей между serial и gpio? (чисто условно) Разве что то, что это будет отрабатывать, условно, 20мс вместо 100мкс, но если это проблема, будет отдельное ТЗ.
Но всем нравится и пипл хавает, создавая на всем этом прикладухи, а потом искренее удивляется, что оно глючит и хер знает как работает. Как выход предлагается все больше памяти и все больше тактовой частоты... но это путь в пропасть и коллапс.
Спасибо за ваше внимание, я закончил. Я бы хотел чтобы это мое сообщение осталось тут "в архивах" :-) Прочтите Книгу по моей ссылке пожалуйста.
Не могу говорить за всех, но я читал. Как первое описание очень даже неплохо, но надо учесть, сколько туда не попало, и что ей концептуально уже лет 20-30 и она не переписывалась... -netch-