Контекстные переключения намного медленнее в новых ядрах Linux
Мы надеемся обновлять ОС на наших серверах из Ubuntu 10.04 LTS к Ubuntu 12.04 LTS. К сожалению, кажется, что задержка для выполнения потока, который стал выполнимым, значительно увеличилась с 2,6 ядер до 3,2 ядер. На самом деле числам задержки, которые мы получаем, трудно верить.
Позвольте мне быть более конкретным относительно теста. У нас есть программа, которая имеет два потока. Первый поток получает текущее время (в галочках с помощью RDTSC) и затем сигнализирует об условной переменной однажды секунда. Второй поток ожидает на условной переменной и просыпается, когда это сообщено. Это затем получает текущее время (в галочках с помощью RDTSC). Различие между временем во втором потоке и время в первом потоке вычислено и отображено на консоли. После этого второй поток ожидает на условной переменной еще раз. Так, мы заставляем поток распараллеливать сигнальное измерение задержки однажды секунда в результате.
В Linux 2.6.32, эта задержка находится где-нибудь на порядке 2.8-3.5 нас, который разумен. В Linux 3.2.0, эта задержка находится где-нибудь на порядке 40-100 нас. Я исключил любые различия в аппаратных средствах между двумя хостами хоста. Они работают на идентичном оборудовании (двойные процессоры X5687 { Westmere-EP } сокета, достигающие 3,6 ГГц с гиперпоточностью, speedstep и всеми выключенными состояниями C). Мы изменяем привязку для выполнения обоих потоков на физических ядрах того же сокета (т.е. первый поток выполняется на Базовом 0, и второй поток выполняется на Базовом 1), таким образом, нет никакого возврата потоков на ядрах или возврата/коммуникации между сокетами.
Единственная разница между двумя хостами - то, что каждый запускает Ubuntu 10.04, LTS с ядром 2.6.32-28 (быстрое поле контекстного переключения) и другой запускает последнюю Ubuntu 12.04 LTS с ядром 3.2.0-23 (медленное поле контекстного переключения).
Были какие-либо изменения в ядре, которое могло составлять, это смешное замедляется в том, сколько времени оно берет, чтобы поток, как планировали, будет работать?
1 ответ
Первое, что пришло на ум я не знаю, почему это было бы, но если это считают как серьезная регрессия производительности Вам, я предлагаю регистрировать ошибку, чтобы заставить члена команды ядра смотреть на нее.