The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +/
Сообщение от opennews (??), 13-Фев-25, 18:50 
Инженер из компании Google предложил повысить частоту генерации прерываний от таймера  в ядре Linux до 1000Hz по умолчанию, что приведёт к увеличению частоты переключения задач и уменьшению кванта времени в планировщике задач. В данный момент по умолчанию используется 250Hz, как некий компромисс между производительностью, задержками и энергопотреблением...

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=62713

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


1. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +3 +/
Сообщение от Аноним (1), 13-Фев-25, 18:50 
А что, дистрибутивы уже собирают ядра с defconfig?
Ответить | Правка | Наверх | Cообщить модератору

2. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +22 +/
Сообщение от opennetuser (ok), 13-Фев-25, 18:51 
Закончится тем, что 1000 это много, а 500 в самый раз. :)
Ответить | Правка | Наверх | Cообщить модератору

17. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +2 +/
Сообщение от Аноним (17), 13-Фев-25, 19:27 
Глянул специально ядро. Есть варианты: 100, 250, 300, 1000. Но как я понял, можно и пропатчить, если сильно надо.
Ответить | Правка | Наверх | Cообщить модератору

81. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  –8 +/
Сообщение от Аноним (-), 14-Фев-25, 06:26 
>можно и пропатчить, если сильно надо.

Этот жаргон меня уже достал. Можно сконфигурировать исходники ядра, выставив частоту в 1000 Гц и заново скомпилировать. Наложение патча это другое действие.

Ответить | Правка | Наверх | Cообщить модератору

99. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +15 +/
Сообщение от sotlef (ok), 14-Фев-25, 10:10 
Тут необходимо именно пропатчить, чтобы в списке частот появилась частота 500 Гц
Ответить | Правка | Наверх | Cообщить модератору

122. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +3 +/
Сообщение от zog (??), 14-Фев-25, 15:05 
Это не жаргон, а профессиональная лексика. Если у тебя с ней проблемы, то поди вон из профессии!
Ответить | Правка | К родителю #81 | Наверх | Cообщить модератору

128. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  –2 +/
Сообщение от Аноним (-), 14-Фев-25, 15:40 
Профессиональная лексика должна озвучиваться по делу. А иначе, это жаргон.
Ответить | Правка | Наверх | Cообщить модератору

91. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  –2 +/
Сообщение от Аноним (91), 14-Фев-25, 08:29 
Пользуюсь исключительно 2000HZ - оптимально для виртуализации окон.
Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

92. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +/
Сообщение от Аноним (91), 14-Фев-25, 08:31 
Стоит отметить нормальную работу вплоть до 3000HZ. На частоте 4000HZ система уже не загружалась.
Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

112. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +/
Сообщение от Аноним (-), 14-Фев-25, 13:46 
Откуда ты такие таймеры берёшь? Они определённо не ядровские.
Ответить | Правка | Наверх | Cообщить модератору

135. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +/
Сообщение от Аноним (91), 14-Фев-25, 16:08 
Достаточно отредактировать один файл и можно добавить любые интересующие вас значения.
Ответить | Правка | Наверх | Cообщить модератору

136. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +/
Сообщение от Аноним (136), 14-Фев-25, 16:11 
Неплохо бы было, если бы в рантайме можно было переключать эти герцы.
Ответить | Правка | Наверх | Cообщить модератору

138. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +1 +/
Сообщение от Аноним (-), 14-Фев-25, 16:56 
Блин, как же ядерщики не додумались об этом а? Наверно, работа операционной системы станет не стабильной?
Ответить | Правка | Наверх | Cообщить модератору

143. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +/
Сообщение от Аноним (136), 14-Фев-25, 17:16 
А что, всех прям нужно обязать делать это непременно? "Все нормальные" даже и не догадались бы о существовании такой возможности. А те, кому надо поэкспериментировать, воспользовались бы.
Ответить | Правка | Наверх | Cообщить модератору

19. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +4 +/
Сообщение от Oe (?), 13-Фев-25, 19:28 
Закончиться динамической частотой таймера. Я её даже на ардуинке делал, пока есть задачи 1000 Гц, когда задач нет можно дропать до 100 Гц чтобы проц не пробуждался часто.
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

25. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +3 +/
Сообщение от Аноним (25), 13-Фев-25, 19:41 
Все уже давно придумано до вас. В dynticks ядрах (типовые дистровые ядра обычно с ним собраны) - если делать нечего, таймер и не дергают. Как видите это однако не всегда срабатывает, как в том примере когда группировка таймеров не удалась. С другой стороны группировка означает что таймеры были - весьма неточные, и латенси отстойная.

> Я её даже на ардуинке делал, пока есть задачи 1000 Гц,
> когда задач нет можно дропать до 100 Гц чтобы проц не пробуждался часто

А на STM32 вообще можно DVFS делать, если не лениво. Надоело молотить на всю катушку? Можно закрутить делитель частоты и свалить на мизерную частоту. А у некоторых и вовсе - переключился на допустим часовой кварц, проц на 32 кГц конечно не чемпион производительности, но неспешно смотреть на кнопки или что там - хватит, а кушает на такой частоте - микроамперы. У некоторых есть и понижение вольтажа Vcore, но вот с ним можно откушать все прелести реализатор DVFS сполна. Т.е. неправильное секвенсирование смены вольтажа и частоты - запросто дестабилизирует чип.

Ответить | Правка | Наверх | Cообщить модератору

76. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  –4 +/
Сообщение от Аноним (76), 14-Фев-25, 01:56 
в винде так сделано из коробки :) т.е. по дефолту 64 или 100гц, а если софтине нужно больше, то она сама выставляет нужный таймер.
Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

86. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +/
Сообщение от n00by (ok), 14-Фев-25, 07:55 
А в каком году документировали такой эффект от вызова timeBeginPeriod()? Я этот момент не застал, в нулевых пришлось расковырять планировщик полностью, начиная с ISR таймера, что бы обосновать "всем известный" хак.
Ответить | Правка | Наверх | Cообщить модератору

105. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +1 +/
Сообщение от Аноним (91), 14-Фев-25, 11:18 
Взять хотя бы 2025 Server: точность таймера выставляется на 0.5мс, глобально для всей системы. Windows 11 24H2 - 1ms, но уже для приложений, локально.
Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

154. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +1 +/
Сообщение от nrv (ok), 15-Фев-25, 04:36 
ага
и там безальтернативно впилен .NET Framework, в который впилен XAML
который для своей отрисовки ставит свою частоту
на которую потом ругается powercfg /energy
..если это, конечно, сабж
Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

21. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +4 +/
Сообщение от Аноним (-), 13-Фев-25, 19:35 
> Закончится тем, что 1000 это много, а 500 в самый раз. :)

Смотря для чего. На обычном десктопе - вы точно хотите 1000Гц, для уменьшения латенси и уменьшения всяких нездоровых дергов. Ибо чем быстрее шедулинг задач - тем ниже латенси каждой задачи. Быстрее очередь доходит до энного желающего пожрать ресурсы проца.

Это разумеется ведет к некоему оверхеду. Однако в "full dynticks" ядрах эффект не такой уж и большой - ибо если известно что в энный момент делать нечего, то и прерывания от таймера скипаются, что частично аннулирует аргументы второго инженера из гугля.

Как видно из бенчей - результат разный и всяко плюс-минус считанные проценты. На десктопе и лаптопе более приятный десктоп от более низкой латенси - явно перевешивает экрномию на спичках.

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

83. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +1 +/
Сообщение от Аноним (-), 14-Фев-25, 06:35 
Если у тебя нездоровые дёрги, то частота тут не причём.
Ответить | Правка | Наверх | Cообщить модератору

121. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +/
Сообщение от Аноним (-), 14-Фев-25, 15:03 
> Если у тебя нездоровые дёрги, то частота тут не причём.

Не у меня а у системы. Которая лагает и дергается на таких вещах. И когда это превышает порог заметности для человека - это отстойный user experience.

Ответить | Правка | Наверх | Cообщить модератору

127. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +/
Сообщение от Аноним (-), 14-Фев-25, 15:36 
>Не у меня а у системы.

Я понял. что не у тебя.

>Которая лагает и дергается на таких вещах. И когда это превышает порог заметности для человека - это отстойный user experience.

В глюках твоего компа частота таймер не играет никакого значения.

Ответить | Правка | Наверх | Cообщить модератору

151. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +/
Сообщение от Аноним (-), 14-Фев-25, 20:10 
> В глюках твоего компа частота таймер не играет никакого значения.

Эффекты от конечности кванта времени - глюками не являются, для начала. Если уж хочется казаться умным - неплохо бы понять хотя-бы вот это.

Ответить | Правка | Наверх | Cообщить модератору

89. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +2 +/
Сообщение от Андрей (??), 14-Фев-25, 08:16 
Только "лаптоп"(лапаный топ?) будет работать меньше от аккума, а пресловутая "латенси" не будет сильно заметна глазу, что собственно и по бенчмаркам заметно, где прирост есть, но всего 5-10% и нигде не указан расход энергии, ибо если +5-10% по скорости и -20% автономности ноутов, то тут ещё стоит подумать.
Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

96. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +1 +/
Сообщение от Оно ним (?), 14-Фев-25, 09:36 
Вообще-то прямо здесь в статье указан расход, если вы посмотрите буквально следующий абзац. Видно, что среднее и максимальное энергопотребление не отличаются, только минимальное на 250 Гц ниже. Из чего можно сделать вывод, что на 1000Гц слегка сократится работа в режиме простоя, и то вряд ли значительно.
Ответить | Правка | Наверх | Cообщить модератору

123. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  –1 +/
Сообщение от Аноним (-), 14-Фев-25, 15:09 
> Только "лаптоп"(лапаный топ?) будет работать меньше от аккума, а пресловутая "латенси"
> не будет сильно заметна глазу,

С full dynticks - мой на 1000Hz работает от батареи более 7 часов. Мне хватает. Это примерно столько же сколько эта модель живет в винде.

> что собственно и по бенчмаркам заметно,

По бенчмаркам заметно что
1) Вообще зависит от характера задачи. Однозначного победителя нет.
2) Даже если, то разница - несколько процентов. А дергания допустим интерфейса пользователя - это неприятно.

Зачем жрать третий сорт, когда можно первый - я не понимаю.

> где прирост есть, но всего 5-10% и нигде не указан расход
> энергии, ибо если +5-10% по скорости и -20% автономности ноутов, то
> тут ещё стоит подумать.

Абсолютно no-brainer choice, с full dynticks никаких 20% прироста времени работы явно не будет. На малохольных мобилках, валяющихся в почти-idle большую часть времени, дрями, с мизерным жором в idle - там еще возможны какие-то варианты. Как второй инженер намерял. Но на более обычном компе, даже лаптопе, это неоправданные мучения. На вон том - приблуда на электроне будет лагать так что до проблем таскшедулинга дело просто не дойдет и никто разницу не заметит.

Ответить | Правка | К родителю #89 | Наверх | Cообщить модератору

101. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +1 +/
Сообщение от _kp (ok), 14-Фев-25, 11:00 
Я с 2011 года использую 1000Гц, и всё хорошо, никаких противопоказаний, одни плюсы.
Странно что до сих под воду в ступе толкут.
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

113. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  –1 +/
Сообщение от Аноним (-), 14-Фев-25, 13:51 
Люди уже перестали сами компилировать ядро. Молча жрут обще-дистрибутивное ядро. Смеканешь.
Ответить | Правка | Наверх | Cообщить модератору

174. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +/
Сообщение от Аноним (174), 16-Фев-25, 13:55 
как то на хабре видел пример того что 300 хорошо делится сразу и на 50 (25) и на 60 (30) - отсюда более оптимальная работа графики с частотой дискретизыции, соответственно, на мониорах/телевизорах в том числе при воспроизведении видео и частично борется с тирингом
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

3. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  –16 +/
Сообщение от Аноним (3), 13-Фев-25, 18:51 
Теперь понятно почему люди с высокими герцами у моника топили за то, что оно не хуже и даже лучше обычных 60. Оно работало на тех же 60.)
Ответить | Правка | Наверх | Cообщить модератору

10. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +8 +/
Сообщение от Шарп (ok), 13-Фев-25, 19:08 
Там написано про джиттер. Ты не понял и полез комментировать.
Ответить | Правка | Наверх | Cообщить модератору

16. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  –8 +/
Сообщение от Oe (?), 13-Фев-25, 19:26 
Лучше бы сделали синхронизацию таймера с частотой монитора, непонятно почему это до сих пор не сделано, а сейчас уже не нужно ибо freesync. Интересно, сколько еще времени пройдет пока компьютер начнет работать с временем нормально? Видео только на аппаратных плеерах нормально можно смотреть, на компьютерах сплошной джиттер кадров.
Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

26. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +3 +/
Сообщение от Аноним (25), 13-Фев-25, 19:49 
> Лучше бы сделали синхронизацию таймера с частотой монитора, непонятно
> почему это до сих пор не сделано

Потому что изначально это вообще совсем разные, независимые подсистемы, внезапно.

То-есть у видяхи на борту - встроен хардварный блок, типа ультра-продвинутого DMA который гонит кусок VRAM на экран, синтезируя при этом времянки протокола как надо. Этот блок так изначально - достаточно автономная штука, и ничего ни о каких системных таймерах вообще не знает.

Более того - как вы себе представляете допустим синхронизацию 250 Гц таймера с 120 Гц монитором? Ничего что сие - не делится нацело? Более того - и у таймеров и у интерфейсов могут быть свои соображения по части точности выдаваемых там частот. А с DVFS у системного таймера частота еще и меняться может вроде. Там есть несколько вариантов что юзается как high-precision таймер. Тогда при попытке это сделать имплементер вероятно сойдет с ума от сложности задачи.

Ответить | Правка | Наверх | Cообщить модератору

34. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  –1 +/
Сообщение от Аноним (34), 13-Фев-25, 20:17 
> Ничего что сие - не делится нацело?

Ничего. Не хочет делиться — будем умножать :)

Ответить | Правка | Наверх | Cообщить модератору

84. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +/
Сообщение от Смузихлеб забывший пароль (?), 14-Фев-25, 07:34 
Но ведь гении от разработки видеокарт ещё недавно хотели увязать те же движения мыши с изменением кадра на монике( сдвиг/обрезка ) практически без участия ЦП. Типо, для улучшения визуального ощущения быстрой отрисовки. Хотя, вроде бы, системы тоже разные и не очень-то зависимые

В крайнем случае, можно делать просто множитель кратно частоте экрана. Например, 4-6
Но переделывать придётся много

Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

93. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +/
Сообщение от Аноним (-), 14-Фев-25, 09:11 
> Но ведь гении от разработки видеокарт ещё недавно хотели увязать те же
> движения мыши с изменением кадра на монике( сдвиг/обрезка ) практически без
> участия ЦП. Типо, для улучшения визуального ощущения быстрой отрисовки. Хотя, вроде
> бы, системы тоже разные и не очень-то зависимые

Ну как бы да, со временем - отрастили фичи информирования софта о таймингах рисовки на экран, чтобы тот мог рисовать без тиринга. А прочий page flipping/double buffer чтобы уж совсем наверняка - при этом есть 2 видеобуфера, один летит в провод, второй рисуется софтом. А когда настало время - указатель переставляется на второй. А софт идет рисовать в первый. Но маневр хоть и избавляет от тиринга, не совсем халявен по латенси, опять же. Ибо теперь вы с гарантией ждете нового кадра, чтобы вывести новый вариант картинки, хоть как.

> В крайнем случае, можно делать просто множитель кратно частоте экрана. Например, 4-6

А ничего что источник тактовых частот железок - изначально - разный? Поэтому вот так жестко - их тайминги друг на друга не завязаны. Это _асинхронные_ процессы, которые могут разбежаться по времени без специальных мер. То что оно где-то там относительно асинхронно может информировать что вот тут у нас vblank - ну да, однако это несколько иное чем жестко подвязывать на это процессы на основном проце.

Так то оно IRQ какой-нибудь сделает, сообщив процу - что - мол, так и так, хочу фрейм. Но если пытаться жестко подвязать к этому шедулинг задач... придется сделать какой-то жуткий изврат, типа софтварного (!!!) PLL - который утрясает расхождение частот железок по ходу пьесы. Без этого дикого изврата тайминги постепенно уедут - и оно будет делать вообще совсем не то что вы представляли, выбивая почву из под ног в максимально неудобный для этого момент.

> Но переделывать придётся много

Это вообще приведет к очень странным извращениям которые совсем не факт что будут очень хорошо работать. И Linux все же - generic операционка, не только для десктопов. Насколько такой кошмарик оправдан - большой вопрос.

Ответить | Правка | Наверх | Cообщить модератору

178. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +/
Сообщение от Смузихлеб забывший пароль (?), 17-Фев-25, 13:48 
У многих железок установлена микросхема, в которой определены многие параметры. Вплоть до планок ОЗУ. И ничего, не померли.
По сути, изначально требуется чтобы при начальной загрузке системы подтягивались данные в т.ч из моника и на основе них выставлялись некоторые множители. Они и так выставляются на основе иных параметров, просто именно монитор до последнего не учитывали
Ответить | Правка | Наверх | Cообщить модератору

4. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +11 +/
Сообщение от Аноним (4), 13-Фев-25, 18:52 
Что бы инженеры из Гугла делали без этого чувака с Фороникса.
Ответить | Правка | Наверх | Cообщить модератору

52. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +2 +/
Сообщение от Аноним (52), 13-Фев-25, 21:16 
Передрались.
"Мы овладеваем более высоким стилем спора. Спор без фактов. Спор на темпераменте. Спор, переходящий от голословного утверждения на личность партнера."
Ответить | Правка | Наверх | Cообщить модератору

5. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +/
Сообщение от Ося Бендер (?), 13-Фев-25, 18:54 
Вот так переставив кроватки, достигаем увеличения потока клиентов. Ловко!
Ответить | Правка | Наверх | Cообщить модератору

7. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  –2 +/
Сообщение от Совершенно другой аноним (?), 13-Фев-25, 19:02 
Странно, что никто не сказал, что увеличение частоты повысит накладные расходы, т.к. прерывание предполагает переход из режима пользователя в режим ядра, сохранение регистров, вызов обработчика прерывания, восстановление регистров, а затем возвращение в режим пользователя.
Ответить | Правка | Наверх | Cообщить модератору

8. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +2 +/
Сообщение от Аноним (8), 13-Фев-25, 19:04 
> "так повышение частот генерации прерываний таймера может привести к повышению энергопотребления"
Ответить | Правка | Наверх | Cообщить модератору

14. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +1 +/
Сообщение от Совершенно другой аноним (?), 13-Фев-25, 19:20 
>> "так повышение частот генерации прерываний таймера может привести к повышению энергопотребления"

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

Ответить | Правка | Наверх | Cообщить модератору

102. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +1 +/
Сообщение от _kp (ok), 14-Фев-25, 11:04 
Светлая тема на Олед дисплее увеличит энергопотребление на порядкИ больше, чам частота таймера.
Напомнило экономию на спичках.
Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

18. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +1 +/
Сообщение от Аноним (17), 13-Фев-25, 19:28 
Фороникс говорит, что не всё так однозначно!
Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

51. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +3 +/
Сообщение от Аноним (51), 13-Фев-25, 21:12 
> Фороникс говорит, что не всё так однозначно!

Фороникс говрит, судя по опыту, что неоднозначность там спичечная и для адекватных людей очевидно, что движняка такого не стоит.

Ответить | Правка | Наверх | Cообщить модератору

9. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +2 +/
Сообщение от Шарп (ok), 13-Фев-25, 19:06 
Предлагаю компромисс: динамическое изменение частоты таймера в зависимости от нагрузки и всего такого.
Ответить | Правка | Наверх | Cообщить модератору

13. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +/
Сообщение от НяшМяш (ok), 13-Фев-25, 19:19 
Давно уже так работает, гуглить tickless kernel.
Ответить | Правка | Наверх | Cообщить модератору

59. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +/
Сообщение от Ivan_83 (ok), 13-Фев-25, 22:01 
Это не совсем оно.
Частота о которой идёт речь она про переключение потоков планировщиком, особенно когда потоков больше чем ядер (те почти всегда и особенно под нагрузкой).
Ответить | Правка | Наверх | Cообщить модератору

100. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +/
Сообщение от Аноним (-), 14-Фев-25, 10:43 
> Это не совсем оно.
> Частота о которой идёт речь она про переключение потоков планировщиком, особенно когда
> потоков больше чем ядер (те почти всегда и особенно под нагрузкой).

Tickless - это некая продвинутость для снижения жора энергии от высокого HZ планировщика и уменьшения его негативных эффектов. Идея в том что если кернел видит что делать нечего, оно не дергает систему, не wake up-ит проц - и отвисает в глубоких режимах powersave дальше, до тех пор пока не появится что-то что нужно делать.

Суммарно соответственно система может больше отвисать в экономных режимах, даже если частота переключения задач формально и высокая. А реально - лишь когда поводы есть. Да, как видно в примере с таймерами - иногда это все же ведет к деоптимизации, когда группировка пачки таймеров не удалась. Зато таймеры точнее и латенси системы ниже. При сохранении части бенефитов более низких частот шедулинга. Тот случай когда и на елку залезли, и зад не очень ободрали.

Ответить | Правка | Наверх | Cообщить модератору

75. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +1 +/
Сообщение от Аноним (75), 14-Фев-25, 01:48 
>cat /boot/config-6.12.13-amd64 | grep CONFIG_NO_HZ_FULL
>CONFIG_NO_HZ_FULL=y

В общем - не понятно, о чём буря в стакане.

Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

11. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +4 +/
Сообщение от Аноним (11), 13-Фев-25, 19:17 
А они замеряли потерю производительности на коде, который не спамит потоками потому что по другому никто и не пытался программировать?
Ответить | Правка | Наверх | Cообщить модератору

12. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +2 +/
Сообщение от анон (?), 13-Фев-25, 19:17 
В убунтовском ядре уже стоит HZ_1000. Раньше было только в lowlatency, но теперь и в generic
Ответить | Правка | Наверх | Cообщить модератору

23. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +1 +/
Сообщение от turbo2001 (ok), 13-Фев-25, 19:40 
В божественной федорке тоже 1000
Ответить | Правка | Наверх | Cообщить модератору

114. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +/
Сообщение от Аноним (-), 14-Фев-25, 13:57 
Ты прав на вас хорошо тестируют. Попроси разработчиков частоту в 2000 Гц. В 2 раза это же так круто!
Ответить | Правка | Наверх | Cообщить модератору

120. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +/
Сообщение от turbo2001 (ok), 14-Фев-25, 14:31 
Ты так говоришь, как будто принимать участие в разработке опенсорс продуктов (тестировать) - это какой-то зашквар.
Ответить | Правка | Наверх | Cообщить модератору

144. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +/
Сообщение от Аноним (136), 14-Фев-25, 17:18 
А в Бжественной сколько?
Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

61. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +/
Сообщение от Ivan_83 (ok), 13-Фев-25, 22:06 
И чо?
Во фре сколько себя помню HZ=1000.
Помню игрался давно уже на арме с этим и уменьшение до 250 давало хороший буст, ниже уже разницы не было так заметно.
Но и терминал начинал немного подлагивать.
Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

74. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +1 +/
Сообщение от Аноним (74), 14-Фев-25, 00:54 
Кстати во фре оно при загрузке может задаваться (в loader.conf).. на ванильном ядре. Если не нравится настройка по умолчанию.
Не ясно что мешает в Линуксе сделать так же. Если вдруг кому дефолтные тики "жмут", grub.conf поправил и перегрузился. но нет. нельзя. только пересборка.
Ответить | Правка | Наверх | Cообщить модератору

129. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  –2 +/
Сообщение от Аноним (129), 14-Фев-25, 15:45 
> Кстати во фре оно при загрузке может задаваться (в loader.conf).. на ванильном
> ядре. Если не нравится настройка по умолчанию.
> Не ясно что мешает в Линуксе сделать так же. Если вдруг кому
> дефолтные тики "жмут", grub.conf поправил и перегрузился. но нет. нельзя. только
> пересборка.

Вероятно с статиченым указанием этого - получается более хорощая оптимизация кода. При wakeup проца до 1000 раз в секунду - это некий аргумент.

Если вы будете будить проц 1000 раз в секунду, без оптимизаций, батарейка скиснет значительно быстрее чем того могло бы хотеться. Возможно 1 из секретов почему в фри так голимо с управлением питанием. У фряхи с управлением питанием и оптимизацией потребления очень голимо все.

Ответить | Правка | Наверх | Cообщить модератору

173. "Обсуждение увеличения часты таймера до 1000Hz в ядре Linux"  +/
Сообщение от Аноним (173), 16-Фев-25, 04:21 
> секретов почему в фри так голимо с управлением питанием. У фряхи
> с управлением питанием и оптимизацией потребления очень голимо все.

Голимо ты man'ы читаешь, это точно. УМВР более семи часов, при чём видео безпрерывно стримится. По сравнению с GNU/Linux разница есть, но вообще не большая.
Рекоммендую pkg install powerdxx && man -k dev

Ответить | Правка | Наверх | Cообщить модератору

15. "Обсуждение увеличения часты таймера в ядре Linux до 1000Hz п..."  +1 +/
Сообщение от Аноним (15), 13-Фев-25, 19:26 
Юзаю 100Hz уже 7+ лет и комп не парится.
Ответить | Правка | Наверх | Cообщить модератору

22. "Обсуждение увеличения часты таймера в ядре Linux до 1000Hz п..."  +12 +/
Сообщение от Аноним (22), 13-Фев-25, 19:35 
Лоурайдер...

Попробуй выставить 50Гц как в розетке

Ответить | Правка | Наверх | Cообщить модератору

29. "Обсуждение увеличения часты таймера в ядре Linux до 1000Hz п..."  –2 +/
Сообщение от Аноним (-), 13-Фев-25, 19:54 
> Юзаю 100Hz уже 7+ лет и комп не парится.

Комп то не парится. А вот его владельца будет ожидать отстойный и дерганый experience, ибо решение о том какую задачу вообще пускать - принимается раз в 10 мс. Что довольно дофига, учитывая многопотосночть и вообще число программ и результирующее число претендентов на квант времени. Учитывая что при этом заранее неизвестно что претендент поработает не 10 мс а например 5 и отвалит, шедулинг получается весьма компромиссный.

В общем 100Гц ядра - только для махровых вебсерверов, замурованных в стену. Где никто не заметит +/- 100 мс.

Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

62. "Обсуждение увеличения часты таймера в ядре Linux до 1000Hz п..."  +2 +/
Сообщение от Аноним (15), 13-Фев-25, 22:12 
Чем больше ядер - тем менее актуален планировщик.
Для игорей можно выделить ядра,  которые будут сидеть на процессе. Если процессу хватает ядер, то таймер не нужен (tickless), а увеличение его частоты даст обратный эффект по производительности.
Ответить | Правка | Наверх | Cообщить модератору

69. "Обсуждение увеличения часты таймера в ядре Linux до 1000Hz п..."  +1 +/
Сообщение от Аноним (69), 13-Фев-25, 23:50 
> Чем больше ядер - тем менее актуален планировщик.

Скажи это сейчас интелу)

Ответить | Правка | Наверх | Cообщить модератору

130. "Обсуждение увеличения часты таймера в ядре Linux до 1000Hz п..."  +/
Сообщение от Аноним (129), 14-Фев-25, 15:48 
> Чем больше ядер - тем менее актуален планировщик.

Не, ну если у вас последний EPYC с 192 ядрами, есть шансы что все треды ядра и треды программ конечно найдут свои ядра и будут довольны по уши :). Иначе - это ну вот не факт, их видите ли развелось довольно много.

Просто сделайте ps с выводом по тредам - и посмтрите, есть у вас столько ядер или где? Не забудьте ядерные треды, коих нынче дофига. А что, раз ядер более 1 то и ядро совсем не против threaded стать в таком случае.

Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

180. "Обсуждение увеличения часты таймера в ядре Linux до 1000Hz п..."  +/
Сообщение от roman (??), 17-Фев-25, 22:23 
>Учитывая что при этом заранее неизвестно что претендент поработает не 10 мс а например 5 и отвалит, шедулинг получается весьма компромиссный.

Если софт умер за 5мс то планировщик просто возьмет следующий из очереди, не дожидаясь прерывания, потом сделает его по расписанию еще раз, то есть может быть ситуация что первый отработает 9мс а второй 1мс.

Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

20. "Обсуждение увеличения часты таймера в ядре Linux до 1000Hz п..."  –4 +/
Сообщение от KKK (?), 13-Фев-25, 19:34 
Google уже давно мог бы написать собстенную ОС под свои задачи.
Ответить | Правка | Наверх | Cообщить модератору

27. "Обсуждение увеличения часты таймера в ядре Linux до 1000Hz п..."  +1 +/
Сообщение от Аноним (27), 13-Фев-25, 19:50 
А можно адаптировать готовую ОС под свои задачи, тогда писать ОС не придётся - вот такой вот поворот.
Ответить | Правка | Наверх | Cообщить модератору

28. "Обсуждение увеличения часты таймера в ядре Linux до 1000Hz п..."  +1 +/
Сообщение от Скрудж (?), 13-Фев-25, 19:53 
ОС да, а все драйвера мира (существующие и будущие) - нет. Но толку с ОС, если она не работает с железом?
Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

31. "Обсуждение увеличения часты таймера в ядре Linux до 1000Hz п..."  +/
Сообщение от Аноним (-), 13-Фев-25, 20:01 
> Google уже давно мог бы написать собстенную ОС под свои задачи.

Уже попробвали! "Man Fucshia". Было полкило воплей о захвате мира, линукскапце, который вот-вот, уже почти совсем, еще немного - и пингвинам амба, на андроиде, десктопе и вообще!

Время шло. Куча хипстеров написала... нечто. С драйвером FAT на игого. Оказалось что он почти не тормозит, и почти не жрет память. Но "почти" все портило. Мир все никак не захватывался - недоумевая зачем нужно нечто с тормозным и жручим драйвером FAT и более нифига, "зато от гугли", "зато драйвер на go".

Через несколько лет этого воло... ну в общем занятий непотребством - тима начала о чем-то догадываться. Они задекларили идею переписа дрова - на хрусте! "Для улучшения перфоманса". И пошли переписывать свой инновационный драйвер фата, теперь банановый^W на хрусте. Но к этому моменту менеджмент, увы, тоже стал о чем-то догадываться на тему перспектив проекта. Да и провел тиме децимацию.

А план по захвату мира - был немного урезан. Теперь оно захватывает мир - на паре фоторамок.

Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

32. "Обсуждение увеличения часты таймера в ядре Linux до 1000Hz п..."  +1 +/
Сообщение от Аноним (32), 13-Фев-25, 20:01 
Гугл уже давно не смог написать свою ос Фуксию. Теперь портит ядро.
Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

49. "Обсуждение увеличения часты таймера в ядре Linux до 1000Hz п..."  +2 +/
Сообщение от Аноним (-), 13-Фев-25, 20:52 
Мог бы.
Но зачем? Проще использовать готовый труд сообщества.
Главное направлять его, аки пастух стадо баранов, в нужном направлении.
Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

66. "Обсуждение увеличения часты таймера в ядре Linux до 1000Hz п..."  +/
Сообщение от Шарп (ok), 13-Фев-25, 22:47 
> Google уже давно мог бы написать собстенную ОС под свои задачи.

А он не может. С чего ты решил, что гугл всемогущий. Например это гугловские бойцы придумали архитектуру трансформер, на которой сейчас всякие чат-гпт работают, но они не лидеры в нейросетках.

Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

90. "Обсуждение увеличения часты таймера в ядре Linux до 1000Hz п..."  +/
Сообщение от Аноним (90), 14-Фев-25, 08:19 
Пытался, получилась Фикция.
Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

166. "Обсуждение увеличения часты таймера в ядре Linux до 1000Hz п..."  +1 +/
Сообщение от Онанимб (?), 15-Фев-25, 17:43 
Ну они изначально позиционировали Фуксию как экспериментальную ОС. Ни о каком захвате мира речи не было, всю эту тему раздули блохеры и журнашлюхи.
Ответить | Правка | Наверх | Cообщить модератору

172. "Обсуждение увеличения часты таймера в ядре Linux до 1000Hz п..."  +/
Сообщение от Аноним (172), 15-Фев-25, 23:36 
Всю эту тему раздули на опеннете, нигде за пределами оного никто и не писал, что дескать все, линукс выкинут и будет Фучия
Это реально было просто местечковым бредом
Ответить | Правка | Наверх | Cообщить модератору

170. "Обсуждение увеличения часты таймера в ядре Linux до 1000Hz п..."  +/
Сообщение от name (??), 15-Фев-25, 19:48 
К сожалению, чтобы написать ОС надо обладать какими-то навыками и опытом кроме верчения деревьев на питоне. А индусы-олимпиадники ничего другого не умеють.
Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

30. "Обсуждение увеличения частоты таймера в ядре Linux до 1000Hz..."  +/
Сообщение от Аноним (32), 13-Фев-25, 20:01 
Кто-то визжал в комментах про 500 герцовые Моники вот. Для них и надо.
Ответить | Правка | Наверх | Cообщить модератору

36. "Обсуждение увеличения частоты таймера в ядре Linux до 1000Hz..."  +1 +/
Сообщение от Аноним (36), 13-Фев-25, 20:27 
Вопрос на опережение: возможно ли это будет как-то отключить и вернуть назад? (да, кора дуба и квадратный монитор из 2004, но это не ваше дело)
Ответить | Правка | Наверх | Cообщить модератору

54. "Обсуждение увеличения частоты таймера в ядре Linux до 1000Hz..."  +2 +/
Сообщение от Аноним (54), 13-Фев-25, 21:21 
Там нечего возвращать, буквально лишь поменяли 1 число в конфиге по-умолчанию. Это ни на ком вообще не отразится, так как дистрибутивы в любом случае свои конфиги используют. И да, многие уже давным-давно 1000 HZ используют.

А Core2Duo кстати достаточно современный процессор. Для него таймер этот капля в море, увеличение частоты только приведет к улучшению отзывчивости системы.
Разницу в нагрузке цпу между разными значениями таймера могут увидеть разве что владельцы каких-нибудь совсем музейных 386-ых или embedded кофеварок.

Ответить | Правка | Наверх | Cообщить модератору

56. "Обсуждение увеличения частоты таймера в ядре Linux до 1000Hz..."  +1 +/
Сообщение от scriptkiddis (?), 13-Фев-25, 21:23 
Сижу на 300 и никаких жутчайших лагов и проблем о которых тут пишут нету. ЧЯДНТ?
Ответить | Правка | Наверх | Cообщить модератору

70. "Обсуждение увеличения частоты таймера в ядре Linux до 1000Hz..."  +/
Сообщение от Аноним (69), 13-Фев-25, 23:54 
Ты не сравниваешь, вот что ты не делаешь.
Поставь 1000 и сравни сам.
Ответить | Правка | Наверх | Cообщить модератору

108. "Обсуждение увеличения частоты таймера в ядре Linux до 1000Hz..."  +/
Сообщение от scriptkiddis (?), 14-Фев-25, 12:12 
Ставил сравнивал никакой разницы
Ответить | Правка | Наверх | Cообщить модератору

169. "Обсуждение увеличения частоты таймера в ядре Linux до 1000Hz..."  +/
Сообщение от Аноним (-), 15-Фев-25, 19:05 
> Сижу на 300 и никаких жутчайших лагов и проблем о которых тут
> пишут нету. ЧЯДНТ?

Систему плотно подгрузить не пробовал чтобы шедулинг стал актуален. Если шедулить нечего - то и проблем с этим нет :)


Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

55. "Обсуждение увеличения частоты таймера в ядре Linux до 1000Hz..."  +/
Сообщение от scriptkiddis (?), 13-Фев-25, 21:21 
Как и не наше дело как это отключить и вернуть.
Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

57. "Обсуждение увеличения частоты таймера в ядре Linux до 1000Hz..."  +/
Сообщение от Аноним (172), 13-Фев-25, 21:54 
Сейчас ты можешь поставить HZ_1000, просто в дефолтном конфиге стоит HZ_250
И в мэйнстримных дистрибах мэйнтейнеры ставят HZ_1000
Если ты не на Генту или ЛФС, то скорее всего у тебя и так стоит уже 1000
Если же ты собираешь ядро сам(судя по вопросу нет), то просто сможешь переключить и все
Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

65. "Обсуждение увеличения частоты таймера в ядре Linux до 1000Hz..."  +/
Сообщение от Аноним (65), 13-Фев-25, 22:46 
Посмотрел только что в дебиане CONFIG_HZ_250=y.
Ответить | Правка | Наверх | Cообщить модератору

95. "Обсуждение увеличения частоты таймера в ядре Linux до 1000Hz..."  +/
Сообщение от Аноним (95), 14-Фев-25, 09:35 
ArhcLinux: CONFIG_HZ=300
Ответить | Правка | Наверх | Cообщить модератору

109. "Обсуждение увеличения частоты таймера в ядре Linux до 1000Hz..."  +/
Сообщение от Аноним (172), 14-Фев-25, 13:18 
Я говорил про мэйнстрим, а ты мне пример из маргинальщины
Ответить | Правка | Наверх | Cообщить модератору

147. "Обсуждение увеличения частоты таймера в ядре Linux до 1000Hz..."  +/
Сообщение от Аноним (54), 14-Фев-25, 18:31 
Кхм-кхм. https://gitlab.archlinux.org/archlinux/packaging/packages/li...
> CONFIG_HZ=1000
Ответить | Правка | К родителю #95 | Наверх | Cообщить модератору

37. "Обсуждение увеличения частоты таймера в ядре Linux до 1000Hz..."  +/
Сообщение от Аноним (37), 13-Фев-25, 20:28 
> При использовании дисплеев с частотой обновления 120Hz, типичных для современных [...] мобильных устройств

Уоу, с каких это пор 120 герц типичны для мобил? Сейчас даже 90 герц далеко не на всех, да и то оно по умолчанию выключено, ибо выжирает и без того немощные батареи.

Ответить | Правка | Наверх | Cообщить модератору

41. "Обсуждение увеличения частоты таймера в ядре Linux до 1000Hz..."  +1 +/
Сообщение от Аноним (36), 13-Фев-25, 20:32 
> Сейчас даже 90 герц далеко не на всех, да и то оно по умолчанию выключено, ибо выжирает и без того немощные батареи.

Даже на тех где есть стоит динамическая частота обновления. Но в целом да, 60 это стандарт и будет им ещё не один десяток лет. Даже в айфонах не спешат с этим.

Ответить | Правка | Наверх | Cообщить модератору

53. "Обсуждение увеличения частоты таймера в ядре Linux до 1000Hz..."  +1 +/
Сообщение от Аноним (53), 13-Фев-25, 21:16 
> 60 это стандарт и будет им ещё не один десяток лет

Откройте для себя хотя бы среднебюджетные телефоны. Хотя уже и на самом дешмане часто 90 Гц бывает.

> Даже в айфонах не спешат с этим

«Даже»… в айфонах много с чем не спешат.

Ответить | Правка | Наверх | Cообщить модератору

79. Скрыто модератором  –2 +/
Сообщение от Русская ядерка (-), 14-Фев-25, 05:14 
Ответить | Правка | Наверх | Cообщить модератору

43. "Обсуждение увеличения частоты таймера в ядре Linux до 1000Hz..."  +/
Сообщение от Аноним (43), 13-Фев-25, 20:39 
Я покупал свой хонор в 2022. Уже в то время большинство телефонов от 150 денег имели минимум 90 герц
Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

44. "Обсуждение увеличения частоты таймера в ядре Linux до 1000Hz..."  +3 +/
Сообщение от Аноним (-), 13-Фев-25, 20:41 
> Уоу, с каких это пор 120 герц типичны для мобил? Сейчас даже
> 90 герц далеко не на всех, да и то оно по
> умолчанию выключено, ибо выжирает и без того немощные батареи.

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

Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

80. "Обсуждение увеличения частоты таймера в ядре Linux до 1000Hz..."  +1 +/
Сообщение от Русская ядерка (-), 14-Фев-25, 05:16 
> И емкостью под 6 амперчасов.

Был смартфон в 2011, кажется самсунг гэлэкси 2. Не знаю какая там батарея была, но явно меньше. И хватало его дня на 3, при том, что я с него сидел часами в приложении в контакте, слушал музыку, сёрфал вэб и играл в казуальные игрульки типа энгри бёрдс. Современные телефоны дай бог чтобы до вечера хватило зарядки.

Ответить | Правка | Наверх | Cообщить модератору

71. "Обсуждение увеличения частоты таймера в ядре Linux до 1000Hz..."  +1 +/
Сообщение от Аноним (69), 13-Фев-25, 23:56 
С разморозкой. В смартах уже пару лет как 120 есть, даже в мидле.
И, ты только не падай!, есть экраны с динамической герцовкой 1-144.
Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

73. "Обсуждение увеличения частоты таймера в ядре Linux до 1000Hz..."  +/
Сообщение от Xo (?), 14-Фев-25, 00:08 
Пользователь ифон детектед)
Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

97. "Обсуждение увеличения частоты таймера в ядре Linux до 1000Hz..."  +/
Сообщение от Оно ним (?), 14-Фев-25, 09:42 
Пару месяцев назад купил бюджетный самсунг с 90 Гц - и ничего не выжирает. Спокойно держит сутки, а если игры не гонять, то и двое.
Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

163. "Обсуждение увеличения частоты таймера в ядре Linux до 1000Hz..."  +/
Сообщение от Аноним (172), 15-Фев-25, 10:41 
Poco X3 NFC — среднебюджетник 2021 года, из коробки 120 Hz обновление экрана
Poco M6 Pro — low-бюджетник 2024 года, из коробки 120 Hz обновление экрана

Или ты про совсем какую-то дичь разговор ведешь? У Сяоми вон на миддл-бренде 120 это норма

Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

39. "Обсуждение увеличения частоты таймера в ядре Linux до 1000Hz..."  +/
Сообщение от Аноним (39), 13-Фев-25, 20:30 
> Конфигурация с 1000Hz оказалась быстрее в тестах Llama.cpp, nginx, SuperTuxKart

Что? Опенсорс копирка марио карт теперь является тестом?

Ответить | Правка | Наверх | Cообщить модератору

72. "Обсуждение увеличения частоты таймера в ядре Linux до 1000Hz..."  +2 +/
Сообщение от Аноним (69), 13-Фев-25, 23:57 
линукс гейминг во всей красе)
Ответить | Правка | Наверх | Cообщить модератору

40. "Обсуждение увеличения частоты таймера в ядре Linux до 1000Hz..."  +/
Сообщение от Аноним (40), 13-Фев-25, 20:31 
И кто гуглу запрещает у себя в гугле 1000Hz поставить?
Ответить | Правка | Наверх | Cообщить модератору

46. "Обсуждение увеличения частоты таймера в ядре Linux до 1000Hz..."  +/
Сообщение от Омнонном (?), 13-Фев-25, 20:46 
А предлагатор сборку ядра не осилил пока ещё, только изменение кода.
Ответить | Правка | Наверх | Cообщить модератору

42. "Обсуждение увеличения частоты таймера в ядре Linux до 1000Hz..."  –1 +/
Сообщение от Аноним (42), 13-Фев-25, 20:38 
А че не 1024? Там жеж, насколько я знаю, еще во времена каменного века на PC AT (на XT RTC был не обязательной железкой), RTC генерил IRQ 8 1024 раза в секунду и ниче. Все работало. Не тормозило.
Ответить | Правка | Наверх | Cообщить модератору

48. "Обсуждение увеличения частоты таймера в ядре Linux до 1000Hz..."  –2 +/
Сообщение от Аноним (-), 13-Фев-25, 20:51 
> А че не 1024? Там жеж, насколько я знаю, еще во времена
> каменного века на PC AT (на XT RTC был не обязательной
> железкой), RTC генерил IRQ 8 1024 раза в секунду и ниче.
> Все работало. Не тормозило.

А сейчас это делается чем-то другим, типа HPET или TSC (на x86-64). Они намного более шустрые и потому точные. У других платформ тоже - как правило скоростные, перепрограммируемые таймеры есть.

Ответить | Правка | Наверх | Cообщить модератору

60. "Обсуждение увеличения частоты таймера в ядре Linux до 1000Hz..."  +/
Сообщение от Ivan_83 (ok), 13-Фев-25, 22:04 
HPET как раз не оч любят, типа оно на PCI шине и оверхэд большой, вот TSC типа где то прямо в проце без лишних шин посредине.
Ответить | Правка | Наверх | Cообщить модератору

103. "Обсуждение увеличения частоты таймера в ядре Linux до 1000Hz..."  +1 +/
Сообщение от Аноним (103), 14-Фев-25, 11:04 
Казалось бы, кто мешает аппаратные таймеры юзать, на ходу меняя умножители как на том же STM8?
Или слишком монолитно?

Когда жалуются на оверхед переключения, вспоминаю ту же BeOS где всё на eventloop которые внутри других eventloop и при этом всё нативное ПО, написанное с учётом этого подхода летает и не заикается вообще никогда.

Ответить | Правка | Наверх | Cообщить модератору

132. "Обсуждение увеличения частоты таймера в ядре Linux до 1000Hz..."  +/
Сообщение от Аноним (-), 14-Фев-25, 15:57 
> Казалось бы, кто мешает аппаратные таймеры юзать, на ходу меняя умножители как
> на том же STM8?
> Или слишком монолитно?

Слишком копролитно, x86-64 - это вам не оно, поэтому все оверинженернутее, навороченнее, и с более 9000 наслоений. А чтоб вы не скучали - DVFS еще и частоту проца меняет постоянно. И вот попробуйте теперь миллисекунду отмерять. Что, не так то просто?

Не знаю на счет STM8, а в STM32 при реклоке - приходится и источники времени репрограмить. Но там я обычно не прыгаю как белка туда сюда, и это несколько проще.

> Когда жалуются на оверхед переключения, вспоминаю ту же BeOS где всё на
> eventloop которые внутри других eventloop и при этом всё нативное ПО,
> написанное с учётом этого подхода летает и не заикается вообще никогда.

Проблема не в event loop а в том что например сохранение и восстановление контекста - особенно по 1000 раз в секунду - это не совсем халявная операция. У x86 в отличие от STM8 state довольно большой и может включать в себя всякие FPU, SIMD и проч. У этого вашего STM8 такой проблему нету конечно, он может намного бойчее вертеться в IRQ и проч :D. А если вы на x86 такие скорости IRQ попробуете - вам не понравится.

Ответить | Правка | Наверх | Cообщить модератору

145. "Обсуждение увеличения частоты таймера в ядре Linux до 1000Hz..."  +/
Сообщение от Аноним (136), 14-Фев-25, 17:21 
А если какой нибудь loop подвесится?
Ответить | Правка | К родителю #103 | Наверх | Cообщить модератору

131. "Обсуждение увеличения частоты таймера в ядре Linux до 1000Hz..."  +/
Сообщение от Аноним (129), 14-Фев-25, 15:53 
> HPET как раз не оч любят, типа оно на PCI шине и
> оверхэд большой, вот TSC типа где то прямо в проце без
> лишних шин посредине.

Так оно вроде TSC и юзает - если это получилось - в порядке приоритета. На некоторых системах однако я встречал ор что мол "clock source unstable" - и тогда fallback на HPET по моему. Но это относительно экзотичный сценарий. Чаще всего и правда TSC.

Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

106. "Обсуждение увеличения частоты таймера в ядре Linux до 1000Hz..."  +/
Сообщение от Аноним (91), 14-Фев-25, 11:30 
HPET - давно превратился в рудименты. И все потому, что достаточно медленный. Проблема усугубляется, когда ядер в процессоре больше двух - тут производительность падает просто катастрофически.
Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

45. "Обсуждение увеличения частоты таймера в ядре Linux до 1000Hz..."  –3 +/
Сообщение от Омнонном (?), 13-Фев-25, 20:45 
Очередной хре с горы ниасилив решение своих задач, пытается решить их за счёт всех остальных.
Ответить | Правка | Наверх | Cообщить модератору

58. "Обсуждение увеличения частоты таймера в ядре Linux до 1000Hz..."  +2 +/
Сообщение от Ivan_83 (ok), 13-Фев-25, 21:59 
Фиговые инженегры у гугла, всякую чушь пишут.

Никто не написал что при частом переключении контекстов повышается отзывчивость всяких десктопов/интерактивов но при этом же увеличивается вымывание кешей из за более меньшего кванта времени работы одной задачи на одном ядре - те жручие задачи начинают медленее работать.

Частота влияет на планировщик задач, поэтому per process оно не полуится сделать, по крайней мере без переделок шедуллера и прочих соседних внутренностей ядра.

Ответить | Правка | Наверх | Cообщить модератору

87. "Обсуждение увеличения частоты таймера в ядре Linux до 1000Hz..."  +1 +/
Сообщение от n00by (ok), 14-Фев-25, 08:06 
Что бы повысить отзывчивость, достаточно уменьшать квант для "интерактивных потоков". Что делается в Виндос, а потому об этом говорить как бы неприлично. :)
Ответить | Правка | Наверх | Cообщить модератору

98. "Обсуждение увеличения частоты таймера в ядре Linux до 1000Hz..."  +1 +/
Сообщение от Ivan_83 (ok), 14-Фев-25, 09:48 
А ты пойди найди на линухе такие процессы :)
Это в венде с геум втащенным в ядро есть за что зацепится при поиске интерактивных.
И насколько я понимаю там не уменьшение кванта времени а повышение приоритета.
Ответить | Правка | Наверх | Cообщить модератору

104. "Обсуждение увеличения частоты таймера в ядре Linux до 1000Hz..."  +1 +/
Сообщение от Аноним (103), 14-Фев-25, 11:08 
Виндовый планировщик и в QoS умеет, чего уж там. Только в лучших традициях всё упирается в кривизну прикладного ПО.
Причём после ухода Балмера даже родные тулзы делаются абы как и без учёта всего этого.
Ответить | Правка | Наверх | Cообщить модератору

133. "Обсуждение увеличения частоты таймера в ядре Linux до 1000Hz..."  +/
Сообщение от Аноним (-), 14-Фев-25, 16:00 
> Виндовый планировщик и в QoS умеет, чего уж там. Только в лучших
> традициях всё упирается в кривизну прикладного ПО.
> Причём после ухода Балмера даже родные тулзы делаются абы как и без
> учёта всего этого.

Учитывая что там часть от большого ума стала на дотнете - ЭТОМУ блоатваре никакие планировщики не помогут! Обречено умереть тормозным дерганым лаговищем.

Ответить | Правка | Наверх | Cообщить модератору

125. "Обсуждение увеличения частоты таймера в ядре Linux до 1000Hz..."  +/
Сообщение от n00by (ok), 14-Фев-25, 15:29 
Да, там реализовано временным повышением приоритета. А как иначе? Два таймера - по каждому на свой тип потоков? Если правильно помню, выделялось по три кванта на поток, но повышенный динамический приоритет позволял влезть меж этими квантами вне очереди.
Ответить | Правка | К родителю #98 | Наверх | Cообщить модератору

94. "Обсуждение увеличения частоты таймера в ядре Linux до 1000Hz..."  +/
Сообщение от Аноним (94), 14-Фев-25, 09:33 
весь проц должен отжирать шедуллер, а не ваши процессы! иначе не пойдёте покупать новый девайс
Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

63. "Обсуждение увеличения частоты таймера в ядре Linux до 1000Hz..."  +/
Сообщение от Аноним (15), 13-Фев-25, 22:28 
Сомневаюсь что патч будет принят.
Скорее Линус поржёт и закроет Юсуфу доступ.
Ответить | Правка | Наверх | Cообщить модератору

64. "Обсуждение увеличения частоты таймера в ядре Linux до 1000 Г..."  –1 +/
Сообщение от Аноним (64), 13-Фев-25, 22:32 
А ведь это всё из-за Gnome, который лагает как какой нибудь смартфон Lenovo со вторым андроидом, не нужны нам эти "улучшения" на Openbox, тут и так всё работает отлично.
Ответить | Правка | Наверх | Cообщить модератору

67. "Обсуждение увеличения частоты таймера в ядре Linux до 1000 Г..."  –2 +/
Сообщение от th3m3 (ok), 13-Фев-25, 23:20 
Судя по тестам, лучше оставить как есть. Работает - не трогай!
Ответить | Правка | Наверх | Cообщить модератору

161. "Обсуждение увеличения частоты таймера в ядре Linux до 1000 Г..."  –1 +/
Сообщение от Аноним (172), 15-Фев-25, 09:48 
Хочу тебя расстроить, но «работает — не трогай» это очень плохой девиз придуманный в 90ые, когда для многих что-то настроенное было почти магией
Если что-то работает, но можно улучшить, тем более если это что-то работает как сейчас просто в силу исторических причин, то можно и нужно менять

Тем более, что по факту в дистрибах и так 1000, а тут просто хотят сменить дефолтное значение. То есть тебя это вообще не коснется никак. Тем более под твоей виндой

Ответить | Правка | Наверх | Cообщить модератору

171. "Обсуждение увеличения частоты таймера в ядре Linux до 1000 Г..."  –2 +/
Сообщение от th3m3 (ok), 15-Фев-25, 22:34 
> Тем более под твоей виндой

Мaстдаем не пользуюсь.

Ответить | Правка | Наверх | Cообщить модератору

177. "Обсуждение увеличения частоты таймера в ядре Linux до 1000 Г..."  +/
Сообщение от Аноним (177), 17-Фев-25, 08:54 
> очень плохой девиз придуманный в 90ые

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

Ответить | Правка | К родителю #161 | Наверх | Cообщить модератору

68. "Обсуждение увеличения частоты таймера в ядре Linux до 1000 Г..."  +/
Сообщение от Кроносквад128 (?), 13-Фев-25, 23:30 
Всё уже продумано в 5.6.0 эти только на этапе дао пути
Ответить | Правка | Наверх | Cообщить модератору

77. "Обсуждение увеличения частоты таймера в ядре Linux до 1000 Г..."  +/
Сообщение от Балагур (?), 14-Фев-25, 03:06 
Инженеров linux у нас не осталось, судя по комментариям и самому посту. У нас уже тысячу лет в ядре вытесняющая многозадачность, а не кооперативная, да ещё и умная. Если процесс в течении своего тика делает sched_yield, а чаще всего он это делает, потому что 1/250 или даже 1/100 процессорного времени какого-нибудь i5 13500 - это слишком много тактов, то скидулер пускает следующий процесс.
Ответить | Правка | Наверх | Cообщить модератору

88. "Обсуждение увеличения частоты таймера в ядре Linux до 1000 Г..."  +/
Сообщение от n00by (ok), 14-Фев-25, 08:10 
"Чаще всего делает" это из разряда "но у меня на виртуалке всё работает!"

Инженер умеет делить и умножать, а потому считает вероятность "всего лишь 1 из миллиона" неприемлемой, учитывая общее количество систем.

Ответить | Правка | Наверх | Cообщить модератору

107. "Обсуждение увеличения частоты таймера в ядре Linux до 1000 Г..."  +/
Сообщение от Балагур (?), 14-Фев-25, 12:01 
Чаще всего делает, именно так, даже если ожидает I/O, то тоже делает, но косвенно. А приложения с бесконечным циклом мы в расчет не берём, все тяжёлые вычисления или на GPU, или распараллеливания, и в принципе, тяжёлые вычисления не критичны к тику, они критичны ко времени CPU.
Ответить | Правка | Наверх | Cообщить модератору

126. "Обсуждение увеличения частоты таймера в ядре Linux до 1000 Г..."  +/
Сообщение от n00by (ok), 14-Фев-25, 15:33 
Вспомнил, Минобразования рекламировал новую корочку диплома, там появилось "инженер". Надеюсь, им преподают теорвер и закон больших чисел в частности, а не только "циклы".
Ответить | Правка | Наверх | Cообщить модератору

150. "Обсуждение увеличения частоты таймера в ядре Linux до 1000 Г..."  +/
Сообщение от Аноним (-), 14-Фев-25, 19:17 
> все тяжёлые вычисления [...] не критичны к тику

А остальные приложения, которые крутятся параллельно этим тяжёлым вычислениям? Это ведь может в рамках одного процесса происходит, это вполне себе паттерн программирования, выкидывать "тяжёлые" вычисления в отдельный поток, так же как в отдельный ядерный поток уходят все блокирующие операции, для того, чтобы основной поток не блокировался бы ни на вводе/выводе, ни на вычислениях, чтобы он мог быстро отреагировать на ввод пользователя или на пакет прилетевший в сетевую карту.

Ответить | Правка | К родителю #107 | Наверх | Cообщить модератору

149. "Обсуждение увеличения частоты таймера в ядре Linux до 1000 Г..."  +/
Сообщение от Аноним (-), 14-Фев-25, 19:14 
> Если процесс в течении своего тика делает sched_yield, а чаще всего он это делает

Ты сейчас про average случай, но если мы говорим о латенси, то более уместно говорить про худший случай. А худший, это когда процесс задумался на каких-то вычислениях, и не делает shed_yield.

> У нас уже тысячу лет в ядре вытесняющая многозадачность, а не кооперативная, да ещё и умная.

Сразу видно "инженера": какое дело кооперативной многозадачности до таймера? Там единственный способ переключения процессов -- это shed_yield или его аналог. Таймер там может хоть с частотой в 100 килогерц генерировать прерывания, активный процесс от этого не перестанет быть активным. Мне кажется, что ты здесь перепутал порядок слов, может ты хотел сказать: "У нас уже тысячу лет в ядре кооперативная многозадачность, а не вытесняющая, да ещё и умная"? Ты ниже примерно так же перепутал циферки:

> потому что 1/250 или даже 1/100 процессорного времени [...] это слишком много тактов

1/100 больше чем 1/250, то есть правильнее было бы написать "1/100 или даже 1/250 -- это слишком много. Может ты так же и кооперативную с вытесняющей многозадачности перепутал? Так ведь, инженер?

Ответить | Правка | К родителю #77 | Наверх | Cообщить модератору

82. "Обсуждение увеличения частоты таймера в ядре Linux до 1000 Г..."  +/
Сообщение от Аноним (82), 14-Фев-25, 06:29 
А если собрать с HZ_10?
Ответить | Правка | Наверх | Cообщить модератору

134. "Обсуждение увеличения частоты таймера в ядре Linux до 1000 Г..."  +/
Сообщение от Аноним (-), 14-Фев-25, 16:02 
> А если собрать с HZ_10?

Kernel slowpoke edition - для самых отборных тормозов и слоупоков, чтобы им обидно не было - так и они смогут насладиться тормозами компьютеров наконец.

Ответить | Правка | Наверх | Cообщить модератору

137. "Обсуждение увеличения частоты таймера в ядре Linux до 1000 Г..."  +/
Сообщение от Аноним (137), 14-Фев-25, 16:46 
Да сделайте уже частоту таймера динамической, пусть автоматически подстраивается под любую систему и её текущее состояние.
Как и всё остальное, но это уже позже и железо поновее будет и технологии.
Ответить | Правка | Наверх | Cообщить модератору

142. "Обсуждение увеличения частоты таймера в ядре Linux до 1000 Г..."  +/
Сообщение от Аноним (-), 14-Фев-25, 17:09 
А на сколько стабильно от всех переключений будут работать подсистемы ядра?
Ответить | Правка | Наверх | Cообщить модератору

164. "Обсуждение увеличения частоты таймера в ядре Linux до 1000 Г..."  +/
Сообщение от Аноним (137), 15-Фев-25, 11:11 
Автоматическая адаптация, адаптивная автоматизация.
Адаптивная синхронизация...
Ответить | Правка | Наверх | Cообщить модератору

146. "Обсуждение увеличения частоты таймера в ядре Linux до 1000 Г..."  –1 +/
Сообщение от tim2k (ok), 14-Фев-25, 17:56 
В FreeBSD с 13.1 kern.hz=1000
Ответить | Правка | Наверх | Cообщить модератору

157. "Обсуждение увеличения частоты таймера в ядре Linux до 1000 Г..."  +/
Сообщение от sysop (?), 15-Фев-25, 08:43 
Получается, ОС для десктопа готова?
Ответить | Правка | Наверх | Cообщить модератору

176. "Обсуждение увеличения частоты таймера в ядре Linux до 1000 Г..."  +/
Сообщение от Аноним (-), 16-Фев-25, 23:19 
А ты 600 Hz (50*120)/10 ей выставить пробовал? Сюрпризы были? (не думаю что будут - я в далёком прошлом выставлял 120 с поллингом, и всё работало - это то-ли семёрка была, то-ли предрелизная бэта восьмёрки...)
Ответить | Правка | К родителю #146 | Наверх | Cообщить модератору

152. "Обсуждение увеличения частоты таймера в ядре Linux до 1000 Г..."  –2 +/
Сообщение от Аноним (152), 14-Фев-25, 21:30 
Все ж просто: посмотрите как сделано в нормальных юниксах современных - MacOS, iOS, iPadOS, tvOS - и сделайте так же. Но нет, пару гуглоидов будут до посинения меряться патчами в рассылке
Ответить | Правка | Наверх | Cообщить модератору

158. "Обсуждение увеличения частоты таймера в ядре Linux до 1000 Г..."  +1 +/
Сообщение от Аноним (-), 15-Фев-25, 08:51 
> Все ж просто: посмотрите как сделано в нормальных юниксах современных - MacOS,
> iOS, iPadOS, tvOS - и сделайте так же. Но нет, пару
> гуглоидов будут до посинения меряться патчами в рассылке

И какой процент например серверов на этом? Ах, примерно нулевой?... Понятия о нормальном - достаточно растяжимое понятие.

Ответить | Правка | Наверх | Cообщить модератору

153. "Обсуждение увеличения частоты таймера в ядре Linux до 1000 Г..."  +1 +/
Сообщение от Аноним (153), 15-Фев-25, 02:59 
А если в системе 32 потока? 32 задачи одновременно могут вообще ни с кем не бороться за ресурсы. Но опять же, если работающих задач в момент времени больше чем кол-во хардварных потоков, то оверхед гораздо меньше так как вычислительных ресурсов достаточно, чтобы это покрывать. По идее, если процесс все ещё требует ресурсов по окончанию кванта времени и при этом ещё есть свободные ресурсы для других задач - ему выделится сразу же следующий квант времени без переключения контекста, но, его выполнение будет прерываться чаще на 1000 "попросту", чем на тех же 250/300. Конечно, если запустить компиляцию в 32 потока, то скорей всего, десктоп на 1000hz будет более отзывчив, но не на столько, чтобы терять в производительности долгоиграющих задач.
Ответить | Правка | Наверх | Cообщить модератору

167. "Обсуждение увеличения частоты таймера в ядре Linux до 1000 Г..."  +/
Сообщение от Jh (?), 15-Фев-25, 18:44 
в генте это вообще не проблема, можно менять при каждой сборке ядра.
Ответить | Правка | Наверх | Cообщить модератору

175. "Обсуждение увеличения частоты таймера в ядре Linux до 1000 Г..."  +/
Сообщение от Аноним (175), 16-Фев-25, 20:12 
По идее, нужно посмотреть как меняется оптимальный интервал на каждом тике. Если он около такой же, то вполне можно предсказывать оптимальный интервал для следующего тика на каждом тике, а не лепить фиксированное значение.
Ответить | Правка | Наверх | Cообщить модератору

179. "Обсуждение увеличения частоты таймера в ядре Linux до 1000 Г..."  +/
Сообщение от Аноним Нелюдимович (?), 17-Фев-25, 17:44 
В патчах К. Коливаса это было уже лет 15 тому назад по умолчанию. Теперь и создатели ванили что-то такое поняли.
©"Горячие финские парни".
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру