LINUX.ORG.RU
решено ФорумAdmin

Изменить clocksource

 , ,


0

1

Привет ЛОР!

Мы поддерживаем форк опенсорсной игры teeworlds. В коде by-design N раз в секунду вызывается функция gettimeofday. В последнее время на сервере увеличилась нагрузка на cpu от инстансов игры и появился iowait до 5%. В коде за это время ничего глобального не менялось. Подцепившись strace к инстансу, видно что часто вызывается сискол gettimeofday.

gettimeofday({1389771308, 455672}, NULL) = 0

Сравнив выхлоп strace с сервера с выхлопом с десктопа, заметил что на десктопе этот сискол не дёргается.

Подозреваю, что различие в том, то на десктопе в качестве clocksource используется tsc, а на сервере в процессе загрузки ядро отказывается использовать tsc:

tsc: Marking TSC unstable due to TSC halts in idle

Пробовал оба доступных на сервере источника hpet и acpi_pm, сисколы не изчезают.

Никак не могу активировать tsc. Пробовал параметр ядра force_tsc_stable=1. Даже если передать ядру опцию clocksource=tsc:

Override clocksource tsc is not HRT compatible. Cannot switch while in HRT/NOHZ mode

★★★

Ну добавьте ещё к параметрам ядра ″nohz=off highres=off″, правда за последствия я не ручаюсь. У вас на сервере в /proc/cpuinfo есть флаг ″constant_tsc″?

mky ★★★★★
()
Ответ на: комментарий от disarmer

Получилось, появились ичточники refined-jiffies jiffies tsc. Но сисколы так и остались даже с tsc

disarmer ★★★
() автор топика

А откуда уверенность, что TSC на сервере юзабелен и ядро просто ошиблось?

Deleted
()

И ещё: у тебя на сервере и на десктопе один и тот же дистрибутив одной и той же версии?

Deleted
()
Ответ на: комментарий от Deleted

С тех пор как выставил tsc время в сравнении с ntp не съехало. Системные вызовы gettimeofday стабильно возвращают монотонно возрастающую последовательность. Как то оно еще может выстрелить?

Да, дистрибутив один, разная архитектура к сожалению. Сервер из бывшего убитого ноута, и там только 32 бита.

disarmer ★★★
() автор топика
Ответ на: комментарий от disarmer

Хм, только вот load avg поднялся до 9 и потребление cpu ядром около 20%.

disarmer ★★★
() автор топика
Ответ на: комментарий от disarmer

Сервер из бывшего убитого ноута, и там только 32 бита.

32 это и есть ответ на ваш вопрос :-)

Вот нагуглил такое:

Concerning gettimeofday(), a vsyscall version for the x86-64 is already part of the vanilla kernel. Patches for i386 exist.

Видимо, для 32-бит патч так и остался патчем, в основное ядро его не включили, поэтому ваш дистрибутив на 64-битах реализует gettimeofday() через vsyscall, а на 32-битах через обычный syscall(). А испточник времени тут не причём. Ну, а дальше думайте сами, либо ищите патч, прикручивайте его к ядру, либо меняйте архитектуру сервера.

mky ★★★★★
()
Ответ на: комментарий от Deleted

Да, но это не объясняет почему syscall вызывается, а вот это объясняет:

Currently the gettimeofday speed up is implemented only for 64 bit architectures (AMD64 and Intel 64) and is not available on x86 machines.

https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_MRG/1.3...

Блин!

disarmer ★★★
() автор топика
Ответ на: комментарий от mky

Спасибо, параллельно то же как раз нагуглил) Кажется пора менять железо

disarmer ★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.