Разные процессоры в одном сервере

Биос такого не будет поддерживать и не заведется. Если предположить что заработало, то куча любого неадекватного поведения биоса. Ещё будет плавающая производительность, шедулер не будет знать где производительность на ядро больше, если она разная.

Kernel panic

В BL485c поддержка HP меняла процессор, и так получилось, что на замену привезли более новый проц.
Так оно и работает по сей день. В сервере 4 процессора. Три из них - шестиядерные оптероны @2400Mhz, а четвертый - шестиядерник @2600Mhz.

Например какой-нибудь шибко умный (интеловский) компилятор может вставить CPUID инструкцию и в зависимости от результата оно будет использовать или SSE2 или SSE3 или вообще не векторизоваться, а потом планировщик ОС может эту задачу на пол пути кинуть на другое ядро, которое не поддерживает те инструкции, и программа просто упадет. Еще можно столкнуться с проблемами сброса кэша инструкций, см. например http://www.mono-project.com/news/2016/09/12/arm64-icache/

Some ARM big.LITTLE CPUs can have cores with different cache line sizes, and pretty much no code out there is ready to deal with it as they assume all cores to be symmetrical.

Есть подтверждения - с чужих слов - работы с процессорами, которые отличаются только частотой. Типа X5650 + X5670. О проблемах не сообщали. С точки зрения софта, от турбобуста на все ядра одного из процессоров, по идее, не отличается.

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

Какой сервер, какой интерконнект между процессорами, и почему так делать нельзя? В !x86 вполне такое бывает. И на x86 тоже бывает, если интерконнет не QPI, а что-то более универсальное, типа PCIe.

Zynq Ultrascale: на одном физическом кристалле сидят 4 шт. 64-битных Cortex A53 и 2 шт. 32-битных Cortex R5. И ещё в логику можно пачку майкроблейзов или опенрисков запихнуть, которые вообще не ARM.

Ну вот в ARM с этим big.LITTLE в итоге огребли проблем из-за разных кэшей

Кто чего огрёб? Посмотри на их ревеню. big.LITTLE не только не закопали, но и расширили (DynamIQ).

Разрабы Mono огребли, как впрочем и разрабы Dolphin и PPSSPP. Эта проблема возникает из-за того, что у разных ядер разные кэши . Это конечно все решается - просто надо сбрасывать по размеру наибольшего кэша. Если же делать например ядра с разными наборами инструкций (но с общим пересекающимся подмножеством), то надо еще или компилировать под это подмножество, или вводить какой-то костыльный механизм чтобы каждое ядро получало только те инструкции, которые оно в состоянии исполнить, в общем опять костыли.

Попоболь студентов, не видевших в жизни ничего, кроме SMP.

+1

Видевшие нестуденты пишут что-то, что могут показать?

Могут рассказать, как бы AMP, пусть и со смешанными ISA, в паре случаев из личной практики очень сильно помогли.

Случай с разными ISA концептуально проще. Не надо думать о миграциях с ядер на ядра. Ну или если о миграции думать, то явно всё. А не так, что вроде работает, но иногда случается боль.

в том случае имплементатор подвел, а именно запихнул дефолтные большое и малое ядро как есть, а есть там разная длина кэш линии - 64 против 32, iirc

Это неправильный SMP, как аноним выше уже отметил. SMP он на то и SMP, что симметричный.

Ты же про AMP писал.

В AMP ничего и не мигрирует.

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

Про PlayStation 3 была какая-то статья, где авторы делали две версии кода обработчиков задач, поэтому каждой было без разницы, где она выполняется. Это было что-то типа миграции, но в полуручном режиме.