Многоядерные процессоры, не трогать переключение контекста

Тут недавно была подобная тема, было обосновано, что это ни разу не увеличит производительность, а иногда даже и ухудшит.

чтобы все процессы выполнялись на одном ядре процесора

Врядли...

а один избранный поток выполнялся бы на другом избранном ядре процессора

Можно, man taskset.

Вообще-то планировщики так и стараются делать, по возможности процесс работает на одном и том же процессоре. Но переключения контекста всё равно будут из-за прерываний

а один избранный поток выполнялся бы на другом избранном ядре процессора?

pthread_setaffinity_np, pthread_getaffinity_np

Кстати интересно куда приходят прерывания в многоядерных системах. Контроллер натравливается наверное на какое-то одно ядро (а при старте на первое, единственно активное). Так что прерываний может и не быть, но любой системный вызов и page/stack фолт таки будут чаще происходить, чем паразитные переключения.

Про стекфолт это я загнул, пардоньте.

виртуалку

Интересно вот что, есть ли такая возможность настроить систему так, чтобы все процессы выполнялись на одном ядре процесора, а один избранный поток выполнялся бы на другом избранном ядре процессора?

no-CB CPU's:
http://lwn.net/Articles/515112/

google://«cpu affinity»

На переключение контекста тратится очень много ресурсов, согласно статье.

на секс тоже тратится очень много ресурсов. Вывод?

Что имеем: избранный поток не страдает от переключения контекста и выполняется на xx% быстрее. Например этим потоком может быть алгоритм сжатия.

это в плюсах. В минусах то, что какой-то ненужный процесс зависнет на своём ядре, и не даст поюзать это ядро какому-то важному новому процессу. Т.е. тормоза. Именно потому ядро принудительно перетасовывает процессы, и это видно, если ты запустишь один процесс — ядро его будет кидать между ядрами.

Кроме того, ты путаешь переключение контекстов и распределение по ядрам. Это разные вещи. Контексты переключались всегда, ещё в MS-DOS(и даже раньше. Аппаратная поддержка есть даже в Z80). А вот ядра появились не так давно. Ядро ОС и без тебя в курсе, и потому не будет переключать процессы без надобности. Если ты конечно не поставишь нескольким процессам сразу RT приоритет. Вот тогда начнётся щелкания и тормоза, за то никакой из RT процессов ничего не пропустит важного.

PS: в сжатии тормозит оперативная память. Она у тебя одна, потому нет никакого смысла раскидывать на несколько процессов или не щелкать. Оно и так постоянно ждёт. Причём ждёт именно RAM, а не кеш. Потому можно смело его прерывать. Работать медленнее оно не будет. Можешь проверить, поставь сжатию nice -20, ядро его не станет щелкать, только в самом крайнем случае. Процесс будет висеть, и «пусть весь мир подождёт». IRL я сжатию 15 ставлю, оно от этого работает точно также быстро. Но не мешает.

Кстати интересно куда приходят прерывания в многоядерных системах.

туда же. Прерывание — это новый процесс и он выполняется на свободном ядре. Если его нет, то берётся несвободное, и прерывается тот процесс, что работает там.

Это несколько усложняет твою картину мира, да? На самом деле, прерывания — та самая «многозадачность», которая была даже в самых первых процессорах. Но ты не одинок, создатели планировщиков тоже об этом не задумываются, в итоге имеем эпичный 12309, и Windows, в котором этого уродства нет. Как и своих «суперпланировщиков»...

Архитектура i486 у меня на полке в туалете лежит (а посрать я мастер). Так что про шлюзы и IDT я в курсе. Я только не понял что значит свободное ядро. Если оно включено, то оно что-то исполняет (ну кроме когда sti hlt), а если нет, то оно в принципе не может просто проснуться и отработать прерывание — слишком дорогая инициализация.

Кстати прерывание может выполняться в той же задаче, если в дескрипторе IDT обычный шлюз вызова, не знаю как в линуксе, а в теории это норма.

Такая возможность есть.

читай интеловскую документацию, про APIC и IO-APIC

Прерывание — это новый процесс и он выполняется на свободном ядре

прерывание - это не процесс, и выполняется оно на том ядре, на котором оно должно выполняться согласно конфигурации контроллера прерываний

это если мы про аппаратные прерывания говорим

А... Лениво. Я с праздным интересом уточнил.

Конкретное прерывание на 386 можно было реализовать отдельной засыпающей задачей, по типу корутины с yield'ом. Но думаю вряд ли это где так сделано, просто шлюзом стеки переключаются, задача та же.

Можешь посмотреть в /proc/interrupts, как прерывания раскидываются по процессорам.
В Линуксах этим занимается демон irqbalance.

в линуксах этим занимается ядро. а демон так, сбоку.

т.е. если irqbalance выключить, прерывания все равно будут раскидываться по разным процессорам?

Будут. irqbalance - это лишь оптимизация прерываний на многопроцессорных системах (NUMA и прочее)

https://www.google.ru/search?q=linux nohz full

Архитектура i486 у меня на полке в туалете лежит (а посрать я мастер). Так что про шлюзы и IDT я в курсе. Я только не понял что значит свободное ядро.

я про многоядерные процессоры. i80486 одноядерный.

прерывай меня полностью

Вот нашел какого-то чувака в теме, разжевывает вопрос в доставки на линуксе. Остальные механизмы должны быть такие же как в 386, по идее.

http://www.alexonlinux.com/smp-affinity-and-proper-interrupt-handling-in-linux