Инженер из компании Google предложил повысить частоту генерации прерываний от таймера в ядре Linux до 1000Hz по умолчанию, что приведёт к увеличению частоты переключения задач и уменьшению кванта времени в планировщике задач. В данный момент по умолчанию используется 250Hz, как некий компромисс между производительностью, задержками и энергопотреблением...Подробнее: https://www.opennet.me/opennews/art.shtml?num=62713
А что, дистрибутивы уже собирают ядра с defconfig?
Закончится тем, что 1000 это много, а 500 в самый раз. :)
Глянул специально ядро. Есть варианты: 100, 250, 300, 1000. Но как я понял, можно и пропатчить, если сильно надо.
>можно и пропатчить, если сильно надо.Этот жаргон меня уже достал. Можно сконфигурировать исходники ядра, выставив частоту в 1000 Гц и заново скомпилировать. Наложение патча это другое действие.
Тут необходимо именно пропатчить, чтобы в списке частот появилась частота 500 Гц
Это не жаргон, а профессиональная лексика. Если у тебя с ней проблемы, то поди вон из профессии!
Профессиональная лексика должна озвучиваться по делу. А иначе, это жаргон.
Пользуюсь исключительно 2000HZ - оптимально для виртуализации окон.
Стоит отметить нормальную работу вплоть до 3000HZ. На частоте 4000HZ система уже не загружалась.
Откуда ты такие таймеры берёшь? Они определённо не ядровские.
Достаточно отредактировать один файл и можно добавить любые интересующие вас значения.
Неплохо бы было, если бы в рантайме можно было переключать эти герцы.
Блин, как же ядерщики не додумались об этом а? Наверно, работа операционной системы станет не стабильной?
А что, всех прям нужно обязать делать это непременно? "Все нормальные" даже и не догадались бы о существовании такой возможности. А те, кому надо поэкспериментировать, воспользовались бы.
Закончиться динамической частотой таймера. Я её даже на ардуинке делал, пока есть задачи 1000 Гц, когда задач нет можно дропать до 100 Гц чтобы проц не пробуждался часто.
Все уже давно придумано до вас. В dynticks ядрах (типовые дистровые ядра обычно с ним собраны) - если делать нечего, таймер и не дергают. Как видите это однако не всегда срабатывает, как в том примере когда группировка таймеров не удалась. С другой стороны группировка означает что таймеры были - весьма неточные, и латенси отстойная.> Я её даже на ардуинке делал, пока есть задачи 1000 Гц,
> когда задач нет можно дропать до 100 Гц чтобы проц не пробуждался частоА на STM32 вообще можно DVFS делать, если не лениво. Надоело молотить на всю катушку? Можно закрутить делитель частоты и свалить на мизерную частоту. А у некоторых и вовсе - переключился на допустим часовой кварц, проц на 32 кГц конечно не чемпион производительности, но неспешно смотреть на кнопки или что там - хватит, а кушает на такой частоте - микроамперы. У некоторых есть и понижение вольтажа Vcore, но вот с ним можно откушать все прелести реализатор DVFS сполна. Т.е. неправильное секвенсирование смены вольтажа и частоты - запросто дестабилизирует чип.
в винде так сделано из коробки :) т.е. по дефолту 64 или 100гц, а если софтине нужно больше, то она сама выставляет нужный таймер.
А в каком году документировали такой эффект от вызова timeBeginPeriod()? Я этот момент не застал, в нулевых пришлось расковырять планировщик полностью, начиная с ISR таймера, что бы обосновать "всем известный" хак.
Взять хотя бы 2025 Server: точность таймера выставляется на 0.5мс, глобально для всей системы. Windows 11 24H2 - 1ms, но уже для приложений, локально.
ага
и там безальтернативно впилен .NET Framework, в который впилен XAML
который для своей отрисовки ставит свою частоту
на которую потом ругается powercfg /energy
..если это, конечно, сабж
> Закончится тем, что 1000 это много, а 500 в самый раз. :)Смотря для чего. На обычном десктопе - вы точно хотите 1000Гц, для уменьшения латенси и уменьшения всяких нездоровых дергов. Ибо чем быстрее шедулинг задач - тем ниже латенси каждой задачи. Быстрее очередь доходит до энного желающего пожрать ресурсы проца.
Это разумеется ведет к некоему оверхеду. Однако в "full dynticks" ядрах эффект не такой уж и большой - ибо если известно что в энный момент делать нечего, то и прерывания от таймера скипаются, что частично аннулирует аргументы второго инженера из гугля.
Как видно из бенчей - результат разный и всяко плюс-минус считанные проценты. На десктопе и лаптопе более приятный десктоп от более низкой латенси - явно перевешивает экрномию на спичках.
Если у тебя нездоровые дёрги, то частота тут не причём.
> Если у тебя нездоровые дёрги, то частота тут не причём.Не у меня а у системы. Которая лагает и дергается на таких вещах. И когда это превышает порог заметности для человека - это отстойный user experience.
>Не у меня а у системы.Я понял. что не у тебя.
>Которая лагает и дергается на таких вещах. И когда это превышает порог заметности для человека - это отстойный user experience.
В глюках твоего компа частота таймер не играет никакого значения.
> В глюках твоего компа частота таймер не играет никакого значения.Эффекты от конечности кванта времени - глюками не являются, для начала. Если уж хочется казаться умным - неплохо бы понять хотя-бы вот это.
Только "лаптоп"(лапаный топ?) будет работать меньше от аккума, а пресловутая "латенси" не будет сильно заметна глазу, что собственно и по бенчмаркам заметно, где прирост есть, но всего 5-10% и нигде не указан расход энергии, ибо если +5-10% по скорости и -20% автономности ноутов, то тут ещё стоит подумать.
Вообще-то прямо здесь в статье указан расход, если вы посмотрите буквально следующий абзац. Видно, что среднее и максимальное энергопотребление не отличаются, только минимальное на 250 Гц ниже. Из чего можно сделать вывод, что на 1000Гц слегка сократится работа в режиме простоя, и то вряд ли значительно.
> Только "лаптоп"(лапаный топ?) будет работать меньше от аккума, а пресловутая "латенси"
> не будет сильно заметна глазу,С full dynticks - мой на 1000Hz работает от батареи более 7 часов. Мне хватает. Это примерно столько же сколько эта модель живет в винде.
> что собственно и по бенчмаркам заметно,
По бенчмаркам заметно что
1) Вообще зависит от характера задачи. Однозначного победителя нет.
2) Даже если, то разница - несколько процентов. А дергания допустим интерфейса пользователя - это неприятно.Зачем жрать третий сорт, когда можно первый - я не понимаю.
> где прирост есть, но всего 5-10% и нигде не указан расход
> энергии, ибо если +5-10% по скорости и -20% автономности ноутов, то
> тут ещё стоит подумать.Абсолютно no-brainer choice, с full dynticks никаких 20% прироста времени работы явно не будет. На малохольных мобилках, валяющихся в почти-idle большую часть времени, дрями, с мизерным жором в idle - там еще возможны какие-то варианты. Как второй инженер намерял. Но на более обычном компе, даже лаптопе, это неоправданные мучения. На вон том - приблуда на электроне будет лагать так что до проблем таскшедулинга дело просто не дойдет и никто разницу не заметит.
Я с 2011 года использую 1000Гц, и всё хорошо, никаких противопоказаний, одни плюсы.
Странно что до сих под воду в ступе толкут.
Люди уже перестали сами компилировать ядро. Молча жрут обще-дистрибутивное ядро. Смеканешь.
как то на хабре видел пример того что 300 хорошо делится сразу и на 50 (25) и на 60 (30) - отсюда более оптимальная работа графики с частотой дискретизыции, соответственно, на мониорах/телевизорах в том числе при воспроизведении видео и частично борется с тирингом
Теперь понятно почему люди с высокими герцами у моника топили за то, что оно не хуже и даже лучше обычных 60. Оно работало на тех же 60.)
Там написано про джиттер. Ты не понял и полез комментировать.
Лучше бы сделали синхронизацию таймера с частотой монитора, непонятно почему это до сих пор не сделано, а сейчас уже не нужно ибо freesync. Интересно, сколько еще времени пройдет пока компьютер начнет работать с временем нормально? Видео только на аппаратных плеерах нормально можно смотреть, на компьютерах сплошной джиттер кадров.
> Лучше бы сделали синхронизацию таймера с частотой монитора, непонятно
> почему это до сих пор не сделаноПотому что изначально это вообще совсем разные, независимые подсистемы, внезапно.
То-есть у видяхи на борту - встроен хардварный блок, типа ультра-продвинутого DMA который гонит кусок VRAM на экран, синтезируя при этом времянки протокола как надо. Этот блок так изначально - достаточно автономная штука, и ничего ни о каких системных таймерах вообще не знает.
Более того - как вы себе представляете допустим синхронизацию 250 Гц таймера с 120 Гц монитором? Ничего что сие - не делится нацело? Более того - и у таймеров и у интерфейсов могут быть свои соображения по части точности выдаваемых там частот. А с DVFS у системного таймера частота еще и меняться может вроде. Там есть несколько вариантов что юзается как high-precision таймер. Тогда при попытке это сделать имплементер вероятно сойдет с ума от сложности задачи.
> Ничего что сие - не делится нацело?Ничего. Не хочет делиться — будем умножать :)
Но ведь гении от разработки видеокарт ещё недавно хотели увязать те же движения мыши с изменением кадра на монике( сдвиг/обрезка ) практически без участия ЦП. Типо, для улучшения визуального ощущения быстрой отрисовки. Хотя, вроде бы, системы тоже разные и не очень-то зависимыеВ крайнем случае, можно делать просто множитель кратно частоте экрана. Например, 4-6
Но переделывать придётся много
> Но ведь гении от разработки видеокарт ещё недавно хотели увязать те же
> движения мыши с изменением кадра на монике( сдвиг/обрезка ) практически без
> участия ЦП. Типо, для улучшения визуального ощущения быстрой отрисовки. Хотя, вроде
> бы, системы тоже разные и не очень-то зависимыеНу как бы да, со временем - отрастили фичи информирования софта о таймингах рисовки на экран, чтобы тот мог рисовать без тиринга. А прочий page flipping/double buffer чтобы уж совсем наверняка - при этом есть 2 видеобуфера, один летит в провод, второй рисуется софтом. А когда настало время - указатель переставляется на второй. А софт идет рисовать в первый. Но маневр хоть и избавляет от тиринга, не совсем халявен по латенси, опять же. Ибо теперь вы с гарантией ждете нового кадра, чтобы вывести новый вариант картинки, хоть как.
> В крайнем случае, можно делать просто множитель кратно частоте экрана. Например, 4-6
А ничего что источник тактовых частот железок - изначально - разный? Поэтому вот так жестко - их тайминги друг на друга не завязаны. Это _асинхронные_ процессы, которые могут разбежаться по времени без специальных мер. То что оно где-то там относительно асинхронно может информировать что вот тут у нас vblank - ну да, однако это несколько иное чем жестко подвязывать на это процессы на основном проце.
Так то оно IRQ какой-нибудь сделает, сообщив процу - что - мол, так и так, хочу фрейм. Но если пытаться жестко подвязать к этому шедулинг задач... придется сделать какой-то жуткий изврат, типа софтварного (!!!) PLL - который утрясает расхождение частот железок по ходу пьесы. Без этого дикого изврата тайминги постепенно уедут - и оно будет делать вообще совсем не то что вы представляли, выбивая почву из под ног в максимально неудобный для этого момент.
> Но переделывать придётся многоЭто вообще приведет к очень странным извращениям которые совсем не факт что будут очень хорошо работать. И Linux все же - generic операционка, не только для десктопов. Насколько такой кошмарик оправдан - большой вопрос.
У многих железок установлена микросхема, в которой определены многие параметры. Вплоть до планок ОЗУ. И ничего, не померли.
По сути, изначально требуется чтобы при начальной загрузке системы подтягивались данные в т.ч из моника и на основе них выставлялись некоторые множители. Они и так выставляются на основе иных параметров, просто именно монитор до последнего не учитывали
Что бы инженеры из Гугла делали без этого чувака с Фороникса.
Передрались.
"Мы овладеваем более высоким стилем спора. Спор без фактов. Спор на темпераменте. Спор, переходящий от голословного утверждения на личность партнера."
Вот так переставив кроватки, достигаем увеличения потока клиентов. Ловко!
Странно, что никто не сказал, что увеличение частоты повысит накладные расходы, т.к. прерывание предполагает переход из режима пользователя в режим ядра, сохранение регистров, вызов обработчика прерывания, восстановление регистров, а затем возвращение в режим пользователя.
> "так повышение частот генерации прерываний таймера может привести к повышению энергопотребления"
>> "так повышение частот генерации прерываний таймера может привести к повышению энергопотребления"это немного не то. Вопрос не про увеличение потребления энергии, а про потерю производительности. В то время, пока процессор бегает по прерыванию он, очевидно, не выполняет какую-либо полезную работу.
Светлая тема на Олед дисплее увеличит энергопотребление на порядкИ больше, чам частота таймера.
Напомнило экономию на спичках.
Фороникс говорит, что не всё так однозначно!
> Фороникс говорит, что не всё так однозначно!Фороникс говрит, судя по опыту, что неоднозначность там спичечная и для адекватных людей очевидно, что движняка такого не стоит.
Предлагаю компромисс: динамическое изменение частоты таймера в зависимости от нагрузки и всего такого.
Давно уже так работает, гуглить tickless kernel.
Это не совсем оно.
Частота о которой идёт речь она про переключение потоков планировщиком, особенно когда потоков больше чем ядер (те почти всегда и особенно под нагрузкой).
> Это не совсем оно.
> Частота о которой идёт речь она про переключение потоков планировщиком, особенно когда
> потоков больше чем ядер (те почти всегда и особенно под нагрузкой).Tickless - это некая продвинутость для снижения жора энергии от высокого HZ планировщика и уменьшения его негативных эффектов. Идея в том что если кернел видит что делать нечего, оно не дергает систему, не wake up-ит проц - и отвисает в глубоких режимах powersave дальше, до тех пор пока не появится что-то что нужно делать.
Суммарно соответственно система может больше отвисать в экономных режимах, даже если частота переключения задач формально и высокая. А реально - лишь когда поводы есть. Да, как видно в примере с таймерами - иногда это все же ведет к деоптимизации, когда группировка пачки таймеров не удалась. Зато таймеры точнее и латенси системы ниже. При сохранении части бенефитов более низких частот шедулинга. Тот случай когда и на елку залезли, и зад не очень ободрали.
>cat /boot/config-6.12.13-amd64 | grep CONFIG_NO_HZ_FULL
>CONFIG_NO_HZ_FULL=yВ общем - не понятно, о чём буря в стакане.
А они замеряли потерю производительности на коде, который не спамит потоками потому что по другому никто и не пытался программировать?
В убунтовском ядре уже стоит HZ_1000. Раньше было только в lowlatency, но теперь и в generic
В божественной федорке тоже 1000
Ты прав на вас хорошо тестируют. Попроси разработчиков частоту в 2000 Гц. В 2 раза это же так круто!
Ты так говоришь, как будто принимать участие в разработке опенсорс продуктов (тестировать) - это какой-то зашквар.
А в Бжественной сколько?
И чо?
Во фре сколько себя помню HZ=1000.
Помню игрался давно уже на арме с этим и уменьшение до 250 давало хороший буст, ниже уже разницы не было так заметно.
Но и терминал начинал немного подлагивать.
Кстати во фре оно при загрузке может задаваться (в loader.conf).. на ванильном ядре. Если не нравится настройка по умолчанию.
Не ясно что мешает в Линуксе сделать так же. Если вдруг кому дефолтные тики "жмут", grub.conf поправил и перегрузился. но нет. нельзя. только пересборка.
> Кстати во фре оно при загрузке может задаваться (в loader.conf).. на ванильном
> ядре. Если не нравится настройка по умолчанию.
> Не ясно что мешает в Линуксе сделать так же. Если вдруг кому
> дефолтные тики "жмут", grub.conf поправил и перегрузился. но нет. нельзя. только
> пересборка.Вероятно с статиченым указанием этого - получается более хорощая оптимизация кода. При wakeup проца до 1000 раз в секунду - это некий аргумент.
Если вы будете будить проц 1000 раз в секунду, без оптимизаций, батарейка скиснет значительно быстрее чем того могло бы хотеться. Возможно 1 из секретов почему в фри так голимо с управлением питанием. У фряхи с управлением питанием и оптимизацией потребления очень голимо все.
> секретов почему в фри так голимо с управлением питанием. У фряхи
> с управлением питанием и оптимизацией потребления очень голимо все.Голимо ты man'ы читаешь, это точно. УМВР более семи часов, при чём видео безпрерывно стримится. По сравнению с GNU/Linux разница есть, но вообще не большая.
Рекоммендую pkg install powerdxx && man -k dev
Юзаю 100Hz уже 7+ лет и комп не парится.
Лоурайдер...Попробуй выставить 50Гц как в розетке
> Юзаю 100Hz уже 7+ лет и комп не парится.Комп то не парится. А вот его владельца будет ожидать отстойный и дерганый experience, ибо решение о том какую задачу вообще пускать - принимается раз в 10 мс. Что довольно дофига, учитывая многопотосночть и вообще число программ и результирующее число претендентов на квант времени. Учитывая что при этом заранее неизвестно что претендент поработает не 10 мс а например 5 и отвалит, шедулинг получается весьма компромиссный.
В общем 100Гц ядра - только для махровых вебсерверов, замурованных в стену. Где никто не заметит +/- 100 мс.
Чем больше ядер - тем менее актуален планировщик.
Для игорей можно выделить ядра, которые будут сидеть на процессе. Если процессу хватает ядер, то таймер не нужен (tickless), а увеличение его частоты даст обратный эффект по производительности.
> Чем больше ядер - тем менее актуален планировщик.Скажи это сейчас интелу)
> Чем больше ядер - тем менее актуален планировщик.Не, ну если у вас последний EPYC с 192 ядрами, есть шансы что все треды ядра и треды программ конечно найдут свои ядра и будут довольны по уши :). Иначе - это ну вот не факт, их видите ли развелось довольно много.
Просто сделайте ps с выводом по тредам - и посмтрите, есть у вас столько ядер или где? Не забудьте ядерные треды, коих нынче дофига. А что, раз ядер более 1 то и ядро совсем не против threaded стать в таком случае.
>Учитывая что при этом заранее неизвестно что претендент поработает не 10 мс а например 5 и отвалит, шедулинг получается весьма компромиссный.Если софт умер за 5мс то планировщик просто возьмет следующий из очереди, не дожидаясь прерывания, потом сделает его по расписанию еще раз, то есть может быть ситуация что первый отработает 9мс а второй 1мс.
Google уже давно мог бы написать собстенную ОС под свои задачи.
А можно адаптировать готовую ОС под свои задачи, тогда писать ОС не придётся - вот такой вот поворот.
ОС да, а все драйвера мира (существующие и будущие) - нет. Но толку с ОС, если она не работает с железом?
> Google уже давно мог бы написать собстенную ОС под свои задачи.Уже попробвали! "Man Fucshia". Было полкило воплей о захвате мира, линукскапце, который вот-вот, уже почти совсем, еще немного - и пингвинам амба, на андроиде, десктопе и вообще!
Время шло. Куча хипстеров написала... нечто. С драйвером FAT на игого. Оказалось что он почти не тормозит, и почти не жрет память. Но "почти" все портило. Мир все никак не захватывался - недоумевая зачем нужно нечто с тормозным и жручим драйвером FAT и более нифига, "зато от гугли", "зато драйвер на go".
Через несколько лет этого воло... ну в общем занятий непотребством - тима начала о чем-то догадываться. Они задекларили идею переписа дрова - на хрусте! "Для улучшения перфоманса". И пошли переписывать свой инновационный драйвер фата, теперь банановый^W на хрусте. Но к этому моменту менеджмент, увы, тоже стал о чем-то догадываться на тему перспектив проекта. Да и провел тиме децимацию.
А план по захвату мира - был немного урезан. Теперь оно захватывает мир - на паре фоторамок.
Гугл уже давно не смог написать свою ос Фуксию. Теперь портит ядро.
Мог бы.
Но зачем? Проще использовать готовый труд сообщества.
Главное направлять его, аки пастух стадо баранов, в нужном направлении.
> Google уже давно мог бы написать собстенную ОС под свои задачи.А он не может. С чего ты решил, что гугл всемогущий. Например это гугловские бойцы придумали архитектуру трансформер, на которой сейчас всякие чат-гпт работают, но они не лидеры в нейросетках.
Пытался, получилась Фикция.
Ну они изначально позиционировали Фуксию как экспериментальную ОС. Ни о каком захвате мира речи не было, всю эту тему раздули блохеры и журнашлюхи.
Всю эту тему раздули на опеннете, нигде за пределами оного никто и не писал, что дескать все, линукс выкинут и будет Фучия
Это реально было просто местечковым бредом
К сожалению, чтобы написать ОС надо обладать какими-то навыками и опытом кроме верчения деревьев на питоне. А индусы-олимпиадники ничего другого не умеють.
Кто-то визжал в комментах про 500 герцовые Моники вот. Для них и надо.
Вопрос на опережение: возможно ли это будет как-то отключить и вернуть назад? (да, кора дуба и квадратный монитор из 2004, но это не ваше дело)
Там нечего возвращать, буквально лишь поменяли 1 число в конфиге по-умолчанию. Это ни на ком вообще не отразится, так как дистрибутивы в любом случае свои конфиги используют. И да, многие уже давным-давно 1000 HZ используют.А Core2Duo кстати достаточно современный процессор. Для него таймер этот капля в море, увеличение частоты только приведет к улучшению отзывчивости системы.
Разницу в нагрузке цпу между разными значениями таймера могут увидеть разве что владельцы каких-нибудь совсем музейных 386-ых или embedded кофеварок.
Сижу на 300 и никаких жутчайших лагов и проблем о которых тут пишут нету. ЧЯДНТ?
Ты не сравниваешь, вот что ты не делаешь.
Поставь 1000 и сравни сам.
Ставил сравнивал никакой разницы
> Сижу на 300 и никаких жутчайших лагов и проблем о которых тут
> пишут нету. ЧЯДНТ?Систему плотно подгрузить не пробовал чтобы шедулинг стал актуален. Если шедулить нечего - то и проблем с этим нет :)
Как и не наше дело как это отключить и вернуть.
Сейчас ты можешь поставить HZ_1000, просто в дефолтном конфиге стоит HZ_250
И в мэйнстримных дистрибах мэйнтейнеры ставят HZ_1000
Если ты не на Генту или ЛФС, то скорее всего у тебя и так стоит уже 1000
Если же ты собираешь ядро сам(судя по вопросу нет), то просто сможешь переключить и все
Посмотрел только что в дебиане CONFIG_HZ_250=y.
ArhcLinux: CONFIG_HZ=300
Я говорил про мэйнстрим, а ты мне пример из маргинальщины
Кхм-кхм. https://gitlab.archlinux.org/archlinux/packaging/packages/li...
> CONFIG_HZ=1000
> При использовании дисплеев с частотой обновления 120Hz, типичных для современных [...] мобильных устройствУоу, с каких это пор 120 герц типичны для мобил? Сейчас даже 90 герц далеко не на всех, да и то оно по умолчанию выключено, ибо выжирает и без того немощные батареи.
> Сейчас даже 90 герц далеко не на всех, да и то оно по умолчанию выключено, ибо выжирает и без того немощные батареи.Даже на тех где есть стоит динамическая частота обновления. Но в целом да, 60 это стандарт и будет им ещё не один десяток лет. Даже в айфонах не спешат с этим.
> 60 это стандарт и будет им ещё не один десяток летОткройте для себя хотя бы среднебюджетные телефоны. Хотя уже и на самом дешмане часто 90 Гц бывает.
> Даже в айфонах не спешат с этим
«Даже»… в айфонах много с чем не спешат.
> в айфонахИ правильно делают. Премиальный продукт vip класса должен быть надёжным и проверенным. И не спорь. Иначе бы все политики и бизнесмены покупали щаоми, а не айфоны.
Я покупал свой хонор в 2022. Уже в то время большинство телефонов от 150 денег имели минимум 90 герц
> Уоу, с каких это пор 120 герц типичны для мобил? Сейчас даже
> 90 герц далеко не на всех, да и то оно по
> умолчанию выключено, ибо выжирает и без того немощные батареи.Немощные батаереи нынче так то - во всю крышку, если вы не заметили. И емкостью под 6 амперчасов. От этого скоро авто можно будет прикуривать! Выжирает их - таки - блевота на электроне, когда кирпич норовит сварить яйца лежа в кармане. Или просто кач гигазов рекламы этим барахлом.
> И емкостью под 6 амперчасов.Был смартфон в 2011, кажется самсунг гэлэкси 2. Не знаю какая там батарея была, но явно меньше. И хватало его дня на 3, при том, что я с него сидел часами в приложении в контакте, слушал музыку, сёрфал вэб и играл в казуальные игрульки типа энгри бёрдс. Современные телефоны дай бог чтобы до вечера хватило зарядки.
С разморозкой. В смартах уже пару лет как 120 есть, даже в мидле.
И, ты только не падай!, есть экраны с динамической герцовкой 1-144.
Пользователь ифон детектед)
Пару месяцев назад купил бюджетный самсунг с 90 Гц - и ничего не выжирает. Спокойно держит сутки, а если игры не гонять, то и двое.
Poco X3 NFC — среднебюджетник 2021 года, из коробки 120 Hz обновление экрана
Poco M6 Pro — low-бюджетник 2024 года, из коробки 120 Hz обновление экранаИли ты про совсем какую-то дичь разговор ведешь? У Сяоми вон на миддл-бренде 120 это норма
> Конфигурация с 1000Hz оказалась быстрее в тестах Llama.cpp, nginx, SuperTuxKartЧто? Опенсорс копирка марио карт теперь является тестом?
линукс гейминг во всей красе)
И кто гуглу запрещает у себя в гугле 1000Hz поставить?
А предлагатор сборку ядра не осилил пока ещё, только изменение кода.
А че не 1024? Там жеж, насколько я знаю, еще во времена каменного века на PC AT (на XT RTC был не обязательной железкой), RTC генерил IRQ 8 1024 раза в секунду и ниче. Все работало. Не тормозило.
> А че не 1024? Там жеж, насколько я знаю, еще во времена
> каменного века на PC AT (на XT RTC был не обязательной
> железкой), RTC генерил IRQ 8 1024 раза в секунду и ниче.
> Все работало. Не тормозило.А сейчас это делается чем-то другим, типа HPET или TSC (на x86-64). Они намного более шустрые и потому точные. У других платформ тоже - как правило скоростные, перепрограммируемые таймеры есть.
HPET как раз не оч любят, типа оно на PCI шине и оверхэд большой, вот TSC типа где то прямо в проце без лишних шин посредине.
Казалось бы, кто мешает аппаратные таймеры юзать, на ходу меняя умножители как на том же STM8?
Или слишком монолитно?Когда жалуются на оверхед переключения, вспоминаю ту же BeOS где всё на eventloop которые внутри других eventloop и при этом всё нативное ПО, написанное с учётом этого подхода летает и не заикается вообще никогда.
> Казалось бы, кто мешает аппаратные таймеры юзать, на ходу меняя умножители как
> на том же STM8?
> Или слишком монолитно?Слишком копролитно, x86-64 - это вам не оно, поэтому все оверинженернутее, навороченнее, и с более 9000 наслоений. А чтоб вы не скучали - DVFS еще и частоту проца меняет постоянно. И вот попробуйте теперь миллисекунду отмерять. Что, не так то просто?
Не знаю на счет STM8, а в STM32 при реклоке - приходится и источники времени репрограмить. Но там я обычно не прыгаю как белка туда сюда, и это несколько проще.
> Когда жалуются на оверхед переключения, вспоминаю ту же BeOS где всё на
> eventloop которые внутри других eventloop и при этом всё нативное ПО,
> написанное с учётом этого подхода летает и не заикается вообще никогда.Проблема не в event loop а в том что например сохранение и восстановление контекста - особенно по 1000 раз в секунду - это не совсем халявная операция. У x86 в отличие от STM8 state довольно большой и может включать в себя всякие FPU, SIMD и проч. У этого вашего STM8 такой проблему нету конечно, он может намного бойчее вертеться в IRQ и проч :D. А если вы на x86 такие скорости IRQ попробуете - вам не понравится.
А если какой нибудь loop подвесится?
> HPET как раз не оч любят, типа оно на PCI шине и
> оверхэд большой, вот TSC типа где то прямо в проце без
> лишних шин посредине.Так оно вроде TSC и юзает - если это получилось - в порядке приоритета. На некоторых системах однако я встречал ор что мол "clock source unstable" - и тогда fallback на HPET по моему. Но это относительно экзотичный сценарий. Чаще всего и правда TSC.
HPET - давно превратился в рудименты. И все потому, что достаточно медленный. Проблема усугубляется, когда ядер в процессоре больше двух - тут производительность падает просто катастрофически.
Очередной хре с горы ниасилив решение своих задач, пытается решить их за счёт всех остальных.
Фиговые инженегры у гугла, всякую чушь пишут.Никто не написал что при частом переключении контекстов повышается отзывчивость всяких десктопов/интерактивов но при этом же увеличивается вымывание кешей из за более меньшего кванта времени работы одной задачи на одном ядре - те жручие задачи начинают медленее работать.
Частота влияет на планировщик задач, поэтому per process оно не полуится сделать, по крайней мере без переделок шедуллера и прочих соседних внутренностей ядра.
Что бы повысить отзывчивость, достаточно уменьшать квант для "интерактивных потоков". Что делается в Виндос, а потому об этом говорить как бы неприлично. :)
А ты пойди найди на линухе такие процессы :)
Это в венде с геум втащенным в ядро есть за что зацепится при поиске интерактивных.
И насколько я понимаю там не уменьшение кванта времени а повышение приоритета.
Виндовый планировщик и в QoS умеет, чего уж там. Только в лучших традициях всё упирается в кривизну прикладного ПО.
Причём после ухода Балмера даже родные тулзы делаются абы как и без учёта всего этого.
> Виндовый планировщик и в QoS умеет, чего уж там. Только в лучших
> традициях всё упирается в кривизну прикладного ПО.
> Причём после ухода Балмера даже родные тулзы делаются абы как и без
> учёта всего этого.Учитывая что там часть от большого ума стала на дотнете - ЭТОМУ блоатваре никакие планировщики не помогут! Обречено умереть тормозным дерганым лаговищем.
Да, там реализовано временным повышением приоритета. А как иначе? Два таймера - по каждому на свой тип потоков? Если правильно помню, выделялось по три кванта на поток, но повышенный динамический приоритет позволял влезть меж этими квантами вне очереди.
весь проц должен отжирать шедуллер, а не ваши процессы! иначе не пойдёте покупать новый девайс
Сомневаюсь что патч будет принят.
Скорее Линус поржёт и закроет Юсуфу доступ.
А ведь это всё из-за Gnome, который лагает как какой нибудь смартфон Lenovo со вторым андроидом, не нужны нам эти "улучшения" на Openbox, тут и так всё работает отлично.
Судя по тестам, лучше оставить как есть. Работает - не трогай!
Хочу тебя расстроить, но «работает — не трогай» это очень плохой девиз придуманный в 90ые, когда для многих что-то настроенное было почти магией
Если что-то работает, но можно улучшить, тем более если это что-то работает как сейчас просто в силу исторических причин, то можно и нужно менятьТем более, что по факту в дистрибах и так 1000, а тут просто хотят сменить дефолтное значение. То есть тебя это вообще не коснется никак. Тем более под твоей виндой
> Тем более под твоей виндойМaстдаем не пользуюсь.
> очень плохой девиз придуманный в 90ыеВидимо ваш девиз больше глючности, изменения всего подряд на совершенно другое, каждое обновление.
Всё уже продумано в 5.6.0 эти только на этапе дао пути
Инженеров linux у нас не осталось, судя по комментариям и самому посту. У нас уже тысячу лет в ядре вытесняющая многозадачность, а не кооперативная, да ещё и умная. Если процесс в течении своего тика делает sched_yield, а чаще всего он это делает, потому что 1/250 или даже 1/100 процессорного времени какого-нибудь i5 13500 - это слишком много тактов, то скидулер пускает следующий процесс.
"Чаще всего делает" это из разряда "но у меня на виртуалке всё работает!"Инженер умеет делить и умножать, а потому считает вероятность "всего лишь 1 из миллиона" неприемлемой, учитывая общее количество систем.
Чаще всего делает, именно так, даже если ожидает I/O, то тоже делает, но косвенно. А приложения с бесконечным циклом мы в расчет не берём, все тяжёлые вычисления или на GPU, или распараллеливания, и в принципе, тяжёлые вычисления не критичны к тику, они критичны ко времени CPU.
Вспомнил, Минобразования рекламировал новую корочку диплома, там появилось "инженер". Надеюсь, им преподают теорвер и закон больших чисел в частности, а не только "циклы".
> все тяжёлые вычисления [...] не критичны к тикуА остальные приложения, которые крутятся параллельно этим тяжёлым вычислениям? Это ведь может в рамках одного процесса происходит, это вполне себе паттерн программирования, выкидывать "тяжёлые" вычисления в отдельный поток, так же как в отдельный ядерный поток уходят все блокирующие операции, для того, чтобы основной поток не блокировался бы ни на вводе/выводе, ни на вычислениях, чтобы он мог быстро отреагировать на ввод пользователя или на пакет прилетевший в сетевую карту.
> Если процесс в течении своего тика делает sched_yield, а чаще всего он это делаетТы сейчас про average случай, но если мы говорим о латенси, то более уместно говорить про худший случай. А худший, это когда процесс задумался на каких-то вычислениях, и не делает shed_yield.
> У нас уже тысячу лет в ядре вытесняющая многозадачность, а не кооперативная, да ещё и умная.
Сразу видно "инженера": какое дело кооперативной многозадачности до таймера? Там единственный способ переключения процессов -- это shed_yield или его аналог. Таймер там может хоть с частотой в 100 килогерц генерировать прерывания, активный процесс от этого не перестанет быть активным. Мне кажется, что ты здесь перепутал порядок слов, может ты хотел сказать: "У нас уже тысячу лет в ядре кооперативная многозадачность, а не вытесняющая, да ещё и умная"? Ты ниже примерно так же перепутал циферки:
> потому что 1/250 или даже 1/100 процессорного времени [...] это слишком много тактов
1/100 больше чем 1/250, то есть правильнее было бы написать "1/100 или даже 1/250 -- это слишком много. Может ты так же и кооперативную с вытесняющей многозадачности перепутал? Так ведь, инженер?
А если собрать с HZ_10?
> А если собрать с HZ_10?Kernel slowpoke edition - для самых отборных тормозов и слоупоков, чтобы им обидно не было - так и они смогут насладиться тормозами компьютеров наконец.
Да сделайте уже частоту таймера динамической, пусть автоматически подстраивается под любую систему и её текущее состояние.
Как и всё остальное, но это уже позже и железо поновее будет и технологии.
А на сколько стабильно от всех переключений будут работать подсистемы ядра?
Автоматическая адаптация, адаптивная автоматизация.
Адаптивная синхронизация...
В FreeBSD с 13.1 kern.hz=1000
Получается, ОС для десктопа готова?
А ты 600 Hz (50*120)/10 ей выставить пробовал? Сюрпризы были? (не думаю что будут - я в далёком прошлом выставлял 120 с поллингом, и всё работало - это то-ли семёрка была, то-ли предрелизная бэта восьмёрки...)
Все ж просто: посмотрите как сделано в нормальных юниксах современных - MacOS, iOS, iPadOS, tvOS - и сделайте так же. Но нет, пару гуглоидов будут до посинения меряться патчами в рассылке
> Все ж просто: посмотрите как сделано в нормальных юниксах современных - MacOS,
> iOS, iPadOS, tvOS - и сделайте так же. Но нет, пару
> гуглоидов будут до посинения меряться патчами в рассылкеИ какой процент например серверов на этом? Ах, примерно нулевой?... Понятия о нормальном - достаточно растяжимое понятие.
А если в системе 32 потока? 32 задачи одновременно могут вообще ни с кем не бороться за ресурсы. Но опять же, если работающих задач в момент времени больше чем кол-во хардварных потоков, то оверхед гораздо меньше так как вычислительных ресурсов достаточно, чтобы это покрывать. По идее, если процесс все ещё требует ресурсов по окончанию кванта времени и при этом ещё есть свободные ресурсы для других задач - ему выделится сразу же следующий квант времени без переключения контекста, но, его выполнение будет прерываться чаще на 1000 "попросту", чем на тех же 250/300. Конечно, если запустить компиляцию в 32 потока, то скорей всего, десктоп на 1000hz будет более отзывчив, но не на столько, чтобы терять в производительности долгоиграющих задач.
в генте это вообще не проблема, можно менять при каждой сборке ядра.
По идее, нужно посмотреть как меняется оптимальный интервал на каждом тике. Если он около такой же, то вполне можно предсказывать оптимальный интервал для следующего тика на каждом тике, а не лепить фиксированное значение.
В патчах К. Коливаса это было уже лет 15 тому назад по умолчанию. Теперь и создатели ванили что-то такое поняли.
©"Горячие финские парни".