The OpenNET Project / Index page

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

Обсуждение увеличения частоты таймера в ядре Linux до 1000 Гц по умолчанию

13.02.2025 18:47

Инженер из компании Google предложил повысить частоту генерации прерываний от таймера в ядре Linux до 1000 Гц по умолчанию, что приведёт к увеличению частоты переключения задач и уменьшению кванта времени в планировщике задач. В данный момент по умолчанию используется 250 Гц, как некий компромисс между производительностью, задержками и энергопотреблением.

При использовании дисплеев с частотой обновления 120 Гц, типичных для современных ПК и мобильных устройств, при частоте таймера 250 Гц неточность квантования времени составляет примерно половину времени кадра, что снижает эффективность распределения ресурсов и не позволяет добиться оптимального соотношения производительности к потреблению энергии. Энергопотребление систем при низкой частоте таймера может оказаться выше, поскольку механизм DVFS (Dynamic Voltage and Frequency Scaling) использует более агрессивную стратегию выбора частоты, чтобы не замедлять выполнение задач.

Возникают ситуации, когда задача уже отработала желаемые операции, требовавшие активных вычислений, но процессор продолжает работу на повышенной частоте из-за конечности кванта времени, который ещё не закончился. Повышение частоты переключения задач может привести к снижению потребления энергии из-за повышения эффективности динамического управления частотой (DVFS), более точного распределения интервалов планировщиком задач, более частого обновления статистики загрузки CPU и уменьшения времени нахождения задач в состоянии ожидания.

Другой инженер из Google предложил оставить частоту таймера как есть (250 Гц), так как повышение частоты генерации прерываний таймера может привести к повышению энергопотребления на маломощных устройствах, таких как платы для интернета вещей. По его оценке при выставлении частоты в 1000 Гц даже на устройствах под управлением Android в некоторых ситуациях зафиксировано повышение потребления энергии процессором на 7%. При увеличении частоты таймера также наблюдается более частое пробуждение CPU, так как при частоте 250 Гц таймеры, установленные на интервалы t + 1 мс, t + 2 мс, t + 3 мс и t + 4 мс, будут сгруппированы и приведут к одному пробуждению, а в случае 1000 Гц произойдёт четыре отдельных пробуждения.

Ресурс Phoronix провёл сравнение производительности ПК на базе CPU AMD Ryzen 9 9950X. Конфигурация с 1000 Гц оказалась быстрее в тестах Llama.cpp, nginx, SuperTuxKart, Selenium и при измерении времени сборки ядра. В тестах Darktable, PostgreSQL, Unvanquished, Xonotic, Blender, SVT-AV1, RawTherapee производительность была выше при установке 250 Гц. При 1000 Гц среднее потребление энергии составило 144.2 Вт, минимальное - 0.18 Вт, максимальное - 202.13 Вт, а при 250 Гц: среднее 144.37 Вт, минимальное 0.07 Вт, максимальное - 202 Вт.



  1. Главная ссылка к новости (https://www.phoronix.com/news/...)
  2. OpenNews: Релиз ядра Linux 6.13
  3. OpenNews: Заметки Теодора Тс'о о ядре Linux, кодексе поведения, ext4, btrfs и ZFS
  4. OpenNews: Ядро Linux достигло отметки в 40 млн строк
  5. OpenNews: Началось продвижение в ядро Linux драйвера Nova для GPU NVIDIA
  6. OpenNews: Прекращение разработки планировщика задач MuQSS и набора патчей "-ck" для ядра Linux
Автор новости: Аноним
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/62713-kernel
Ключевые слова: kernel, timer
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (152) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 18:50, 13/02/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    А что, дистрибутивы уже собирают ядра с defconfig?
     
  • 1.2, opennetuser (ok), 18:51, 13/02/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +22 +/
    Закончится тем, что 1000 это много, а 500 в самый раз. :)
     
     
  • 2.17, Аноним (17), 19:27, 13/02/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Глянул специально ядро. Есть варианты: 100, 250, 300, 1000. Но как я понял, можно и пропатчить, если сильно надо.
     
     
  • 3.81, Аноним (-), 06:26, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • –8 +/
    >можно и пропатчить, если сильно надо.

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

     
     
  • 4.99, sotlef (ok), 10:10, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +15 +/
    Тут необходимо именно пропатчить, чтобы в списке частот появилась частота 500 Гц
     
  • 4.122, zog (??), 15:05, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Это не жаргон, а профессиональная лексика. Если у тебя с ней проблемы, то поди вон из профессии!
     
     
  • 5.128, Аноним (-), 15:40, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Профессиональная лексика должна озвучиваться по делу. А иначе, это жаргон.
     
  • 3.91, Аноним (91), 08:29, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Пользуюсь исключительно 2000HZ - оптимально для виртуализации окон.
     
  • 3.92, Аноним (91), 08:31, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Стоит отметить нормальную работу вплоть до 3000HZ. На частоте 4000HZ система уже не загружалась.
     
     
  • 4.112, Аноним (-), 13:46, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Откуда ты такие таймеры берёшь? Они определённо не ядровские.
     
     
  • 5.135, Аноним (91), 16:08, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Достаточно отредактировать один файл и можно добавить любые интересующие вас значения.
     
     
  • 6.136, Аноним (136), 16:11, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Неплохо бы было, если бы в рантайме можно было переключать эти герцы.
     
     
  • 7.138, Аноним (-), 16:56, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Блин, как же ядерщики не додумались об этом а? Наверно, работа операционной системы станет не стабильной?
     
     
  • 8.143, Аноним (136), 17:16, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    А что, всех прям нужно обязать делать это непременно Все нормальные даже и не... текст свёрнут, показать
     
  • 2.19, Oe (?), 19:28, 13/02/2025 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Закончиться динамической частотой таймера. Я её даже на ардуинке делал, пока есть задачи 1000 Гц, когда задач нет можно дропать до 100 Гц чтобы проц не пробуждался часто.
     
     
  • 3.25, Аноним (25), 19:41, 13/02/2025 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Все уже давно придумано до вас В dynticks ядрах типовые дистровые ядра обычно ... большой текст свёрнут, показать
     
  • 3.76, Аноним (76), 01:56, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • –4 +/
    в винде так сделано из коробки :) т.е. по дефолту 64 или 100гц, а если софтине нужно больше, то она сама выставляет нужный таймер.
     
     
  • 4.86, n00by (ok), 07:55, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    А в каком году документировали такой эффект от вызова timeBeginPeriod()? Я этот момент не застал, в нулевых пришлось расковырять планировщик полностью, начиная с ISR таймера, что бы обосновать "всем известный" хак.
     
  • 4.105, Аноним (91), 11:18, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Взять хотя бы 2025 Server: точность таймера выставляется на 0.5мс, глобально для всей системы. Windows 11 24H2 - 1ms, но уже для приложений, локально.
     
  • 4.154, nrv (ok), 04:36, 15/02/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ага
    и там безальтернативно впилен .NET Framework, в который впилен XAML
    который для своей отрисовки ставит свою частоту
    на которую потом ругается powercfg /energy
    ..если это, конечно, сабж
     
  • 2.21, Аноним (-), 19:35, 13/02/2025 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Закончится тем, что 1000 это много, а 500 в самый раз. :)

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

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

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

     
     
  • 3.83, Аноним (-), 06:35, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Если у тебя нездоровые дёрги, то частота тут не причём.
     
     
  • 4.121, Аноним (-), 15:03, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Если у тебя нездоровые дёрги, то частота тут не причём.

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

     
     
  • 5.127, Аноним (-), 15:36, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    >Не у меня а у системы.

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

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

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

     
     
  • 6.151, Аноним (-), 20:10, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > В глюках твоего компа частота таймер не играет никакого значения.

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

     
  • 3.89, Андрей (??), 08:16, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Только "лаптоп"(лапаный топ?) будет работать меньше от аккума, а пресловутая "латенси" не будет сильно заметна глазу, что собственно и по бенчмаркам заметно, где прирост есть, но всего 5-10% и нигде не указан расход энергии, ибо если +5-10% по скорости и -20% автономности ноутов, то тут ещё стоит подумать.
     
     
  • 4.96, Оно ним (?), 09:36, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вообще-то прямо здесь в статье указан расход, если вы посмотрите буквально следующий абзац. Видно, что среднее и максимальное энергопотребление не отличаются, только минимальное на 250 Гц ниже. Из чего можно сделать вывод, что на 1000Гц слегка сократится работа в режиме простоя, и то вряд ли значительно.
     
  • 4.123, Аноним (-), 15:09, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    С full dynticks - мой на 1000Hz работает от батареи более 7 часов Мне хватает ... большой текст свёрнут, показать
     
  • 2.101, _kp (ok), 11:00, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Я с 2011 года использую 1000Гц, и всё хорошо, никаких противопоказаний, одни плюсы.
    Странно что до сих под воду в ступе толкут.
     
     
  • 3.113, Аноним (-), 13:51, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Люди уже перестали сами компилировать ядро. Молча жрут обще-дистрибутивное ядро. Смеканешь.
     
  • 2.174, Аноним (174), 13:55, 16/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    как то на хабре видел пример того что 300 хорошо делится сразу и на 50 (25) и на 60 (30) - отсюда более оптимальная работа графики с частотой дискретизыции, соответственно, на мониорах/телевизорах в том числе при воспроизведении видео и частично борется с тирингом
     

  • 1.3, Аноним (3), 18:51, 13/02/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –16 +/
    Теперь понятно почему люди с высокими герцами у моника топили за то, что оно не хуже и даже лучше обычных 60. Оно работало на тех же 60.)
     
     
  • 2.10, Шарп (ok), 19:08, 13/02/2025 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Там написано про джиттер. Ты не понял и полез комментировать.
     
  • 2.16, Oe (?), 19:26, 13/02/2025 [^] [^^] [^^^] [ответить]  
  • –8 +/
    Лучше бы сделали синхронизацию таймера с частотой монитора, непонятно почему это до сих пор не сделано, а сейчас уже не нужно ибо freesync. Интересно, сколько еще времени пройдет пока компьютер начнет работать с временем нормально? Видео только на аппаратных плеерах нормально можно смотреть, на компьютерах сплошной джиттер кадров.
     
     
  • 3.26, Аноним (25), 19:49, 13/02/2025 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Потому что изначально это вообще совсем разные, независимые подсистемы, внезапно... большой текст свёрнут, показать
     
     
  • 4.34, Аноним (34), 20:17, 13/02/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Ничего что сие - не делится нацело?

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

     
  • 4.84, Смузихлеб забывший пароль (?), 07:34, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Но ведь гении от разработки видеокарт ещё недавно хотели увязать те же движения мыши с изменением кадра на монике( сдвиг/обрезка ) практически без участия ЦП. Типо, для улучшения визуального ощущения быстрой отрисовки. Хотя, вроде бы, системы тоже разные и не очень-то зависимые

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

     
     
  • 5.93, Аноним (-), 09:11, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Ну как бы да, со временем - отрастили фичи информирования софта о таймингах рисо... большой текст свёрнут, показать
     
     
  • 6.178, Смузихлеб забывший пароль (?), 13:48, 17/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    У многих железок установлена микросхема, в которой определены многие параметры. Вплоть до планок ОЗУ. И ничего, не померли.
    По сути, изначально требуется чтобы при начальной загрузке системы подтягивались данные в т.ч из моника и на основе них выставлялись некоторые множители. Они и так выставляются на основе иных параметров, просто именно монитор до последнего не учитывали
     

  • 1.4, Аноним (4), 18:52, 13/02/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +11 +/
    Что бы инженеры из Гугла делали без этого чувака с Фороникса.
     
     
  • 2.52, Аноним (52), 21:16, 13/02/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Передрались.
    "Мы овладеваем более высоким стилем спора. Спор без фактов. Спор на темпераменте. Спор, переходящий от голословного утверждения на личность партнера."
     

  • 1.5, Ося Бендер (?), 18:54, 13/02/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вот так переставив кроватки, достигаем увеличения потока клиентов. Ловко!
     
  • 1.7, Совершенно другой аноним (?), 19:02, 13/02/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Странно, что никто не сказал, что увеличение частоты повысит накладные расходы, т.к. прерывание предполагает переход из режима пользователя в режим ядра, сохранение регистров, вызов обработчика прерывания, восстановление регистров, а затем возвращение в режим пользователя.
     
     
  • 2.8, Аноним (8), 19:04, 13/02/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > "так повышение частот генерации прерываний таймера может привести к повышению энергопотребления"
     
     
  • 3.14, Совершенно другой аноним (?), 19:20, 13/02/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> "так повышение частот генерации прерываний таймера может привести к повышению энергопотребления"

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

     
  • 3.102, _kp (ok), 11:04, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Светлая тема на Олед дисплее увеличит энергопотребление на порядкИ больше, чам частота таймера.
    Напомнило экономию на спичках.
     
  • 2.18, Аноним (17), 19:28, 13/02/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Фороникс говорит, что не всё так однозначно!
     
     
  • 3.51, Аноним (51), 21:12, 13/02/2025 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Фороникс говорит, что не всё так однозначно!

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

     

  • 1.9, Шарп (ok), 19:06, 13/02/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Предлагаю компромисс: динамическое изменение частоты таймера в зависимости от нагрузки и всего такого.
     
     
  • 2.13, НяшМяш (ok), 19:19, 13/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Давно уже так работает, гуглить tickless kernel.
     
     
  • 3.59, Ivan_83 (ok), 22:01, 13/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Это не совсем оно.
    Частота о которой идёт речь она про переключение потоков планировщиком, особенно когда потоков больше чем ядер (те почти всегда и особенно под нагрузкой).
     
     
  • 4.100, Аноним (-), 10:43, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Tickless - это некая продвинутость для снижения жора энергии от высокого HZ план... большой текст свёрнут, показать
     
  • 3.75, Аноним (75), 01:48, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >cat /boot/config-6.12.13-amd64 | grep CONFIG_NO_HZ_FULL
    >CONFIG_NO_HZ_FULL=y

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

     

  • 1.11, Аноним (11), 19:17, 13/02/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    А они замеряли потерю производительности на коде, который не спамит потоками потому что по другому никто и не пытался программировать?
     
  • 1.12, анон (?), 19:17, 13/02/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    В убунтовском ядре уже стоит HZ_1000. Раньше было только в lowlatency, но теперь и в generic
     
     
  • 2.23, turbo2001 (ok), 19:40, 13/02/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В божественной федорке тоже 1000
     
     
  • 3.114, Аноним (-), 13:57, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Ты прав на вас хорошо тестируют. Попроси разработчиков частоту в 2000 Гц. В 2 раза это же так круто!
     
     
  • 4.120, turbo2001 (ok), 14:31, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Ты так говоришь, как будто принимать участие в разработке опенсорс продуктов (тестировать) - это какой-то зашквар.
     
  • 3.144, Аноним (136), 17:18, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    А в Бжественной сколько?
     
  • 2.61, Ivan_83 (ok), 22:06, 13/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    И чо?
    Во фре сколько себя помню HZ=1000.
    Помню игрался давно уже на арме с этим и уменьшение до 250 давало хороший буст, ниже уже разницы не было так заметно.
    Но и терминал начинал немного подлагивать.
     
     
  • 3.74, Аноним (74), 00:54, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Кстати во фре оно при загрузке может задаваться (в loader.conf).. на ванильном ядре. Если не нравится настройка по умолчанию.
    Не ясно что мешает в Линуксе сделать так же. Если вдруг кому дефолтные тики "жмут", grub.conf поправил и перегрузился. но нет. нельзя. только пересборка.
     
     
  • 4.129, Аноним (129), 15:45, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Кстати во фре оно при загрузке может задаваться (в loader.conf).. на ванильном
    > ядре. Если не нравится настройка по умолчанию.
    > Не ясно что мешает в Линуксе сделать так же. Если вдруг кому
    > дефолтные тики "жмут", grub.conf поправил и перегрузился. но нет. нельзя. только
    > пересборка.

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

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

     
     
  • 5.173, Аноним (173), 04:21, 16/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > секретов почему в фри так голимо с управлением питанием. У фряхи
    > с управлением питанием и оптимизацией потребления очень голимо все.

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

     

  • 1.15, Аноним (15), 19:26, 13/02/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Юзаю 100Hz уже 7+ лет и комп не парится.
     
     
  • 2.22, Аноним (22), 19:35, 13/02/2025 [^] [^^] [^^^] [ответить]  
  • +12 +/
    Лоурайдер...

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

     
  • 2.29, Аноним (-), 19:54, 13/02/2025 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Юзаю 100Hz уже 7+ лет и комп не парится.

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

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

     
     
  • 3.62, Аноним (15), 22:12, 13/02/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Чем больше ядер - тем менее актуален планировщик.
    Для игорей можно выделить ядра,  которые будут сидеть на процессе. Если процессу хватает ядер, то таймер не нужен (tickless), а увеличение его частоты даст обратный эффект по производительности.
     
     
  • 4.69, Аноним (69), 23:50, 13/02/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Чем больше ядер - тем менее актуален планировщик.

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

     
  • 4.130, Аноним (129), 15:48, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Чем больше ядер - тем менее актуален планировщик.

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

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

     
  • 3.180, roman (??), 22:23, 17/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    >Учитывая что при этом заранее неизвестно что претендент поработает не 10 мс а например 5 и отвалит, шедулинг получается весьма компромиссный.

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

     

  • 1.20, KKK (?), 19:34, 13/02/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Google уже давно мог бы написать собстенную ОС под свои задачи.
     
     
  • 2.27, Аноним (27), 19:50, 13/02/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А можно адаптировать готовую ОС под свои задачи, тогда писать ОС не придётся - вот такой вот поворот.
     
  • 2.28, Скрудж (?), 19:53, 13/02/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ОС да, а все драйвера мира (существующие и будущие) - нет. Но толку с ОС, если она не работает с железом?
     
  • 2.31, Аноним (-), 20:01, 13/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Уже попробвали Man Fucshia Было полкило воплей о захвате мира, линукскапце, ... большой текст свёрнут, показать
     
  • 2.32, Аноним (32), 20:01, 13/02/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Гугл уже давно не смог написать свою ос Фуксию. Теперь портит ядро.
     
  • 2.49, Аноним (-), 20:52, 13/02/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Мог бы.
    Но зачем? Проще использовать готовый труд сообщества.
    Главное направлять его, аки пастух стадо баранов, в нужном направлении.
     
  • 2.66, Шарп (ok), 22:47, 13/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Google уже давно мог бы написать собстенную ОС под свои задачи.

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

     
  • 2.90, Аноним (90), 08:19, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Пытался, получилась Фикция.
     
     
  • 3.166, Онанимб (?), 17:43, 15/02/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну они изначально позиционировали Фуксию как экспериментальную ОС. Ни о каком захвате мира речи не было, всю эту тему раздули блохеры и журнашлюхи.
     
     
  • 4.172, Аноним (172), 23:36, 15/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Всю эту тему раздули на опеннете, нигде за пределами оного никто и не писал, что дескать все, линукс выкинут и будет Фучия
    Это реально было просто местечковым бредом
     
  • 2.170, name (??), 19:48, 15/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    К сожалению, чтобы написать ОС надо обладать какими-то навыками и опытом кроме верчения деревьев на питоне. А индусы-олимпиадники ничего другого не умеють.
     

  • 1.30, Аноним (32), 20:01, 13/02/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Кто-то визжал в комментах про 500 герцовые Моники вот. Для них и надо.
     
  • 1.36, Аноним (36), 20:27, 13/02/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Вопрос на опережение: возможно ли это будет как-то отключить и вернуть назад? (да, кора дуба и квадратный монитор из 2004, но это не ваше дело)
     
     
  • 2.54, Аноним (54), 21:21, 13/02/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Там нечего возвращать, буквально лишь поменяли 1 число в конфиге по-умолчанию. Это ни на ком вообще не отразится, так как дистрибутивы в любом случае свои конфиги используют. И да, многие уже давным-давно 1000 HZ используют.

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

     
     
  • 3.56, scriptkiddis (?), 21:23, 13/02/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Сижу на 300 и никаких жутчайших лагов и проблем о которых тут пишут нету. ЧЯДНТ?
     
     
  • 4.70, Аноним (69), 23:54, 13/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Ты не сравниваешь, вот что ты не делаешь.
    Поставь 1000 и сравни сам.
     
     
  • 5.108, scriptkiddis (?), 12:12, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Ставил сравнивал никакой разницы
     
  • 4.169, Аноним (-), 19:05, 15/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Сижу на 300 и никаких жутчайших лагов и проблем о которых тут
    > пишут нету. ЧЯДНТ?

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


     
  • 2.55, scriptkiddis (?), 21:21, 13/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Как и не наше дело как это отключить и вернуть.
     
  • 2.57, Аноним (172), 21:54, 13/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Сейчас ты можешь поставить HZ_1000, просто в дефолтном конфиге стоит HZ_250
    И в мэйнстримных дистрибах мэйнтейнеры ставят HZ_1000
    Если ты не на Генту или ЛФС, то скорее всего у тебя и так стоит уже 1000
    Если же ты собираешь ядро сам(судя по вопросу нет), то просто сможешь переключить и все
     
     
  • 3.65, Аноним (65), 22:46, 13/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Посмотрел только что в дебиане CONFIG_HZ_250=y.
     
     
  • 4.95, Аноним (95), 09:35, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    ArhcLinux: CONFIG_HZ=300
     
     
  • 5.109, Аноним (172), 13:18, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Я говорил про мэйнстрим, а ты мне пример из маргинальщины
     
  • 5.147, Аноним (54), 18:31, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Кхм-кхм. https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/blob/af7d6fd
    > CONFIG_HZ=1000
     

  • 1.37, Аноним (37), 20:28, 13/02/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > При использовании дисплеев с частотой обновления 120Hz, типичных для современных [...] мобильных устройств

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

     
     
  • 2.41, Аноним (36), 20:32, 13/02/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Сейчас даже 90 герц далеко не на всех, да и то оно по умолчанию выключено, ибо выжирает и без того немощные батареи.

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

     
     
  • 3.53, Аноним (53), 21:16, 13/02/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > 60 это стандарт и будет им ещё не один десяток лет

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

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

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

     
     
  • 4.79, Русская ядерка (-), 05:14, 14/02/2025 Скрыто ботом-модератором     [к модератору]
  • –2 +/
     
  • 2.43, Аноним (43), 20:39, 13/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Я покупал свой хонор в 2022. Уже в то время большинство телефонов от 150 денег имели минимум 90 герц
     
  • 2.44, Аноним (-), 20:41, 13/02/2025 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Уоу, с каких это пор 120 герц типичны для мобил? Сейчас даже
    > 90 герц далеко не на всех, да и то оно по
    > умолчанию выключено, ибо выжирает и без того немощные батареи.

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

     
     
  • 3.80, Русская ядерка (-), 05:16, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > И емкостью под 6 амперчасов.

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

     
  • 2.71, Аноним (69), 23:56, 13/02/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    С разморозкой. В смартах уже пару лет как 120 есть, даже в мидле.
    И, ты только не падай!, есть экраны с динамической герцовкой 1-144.
     
  • 2.73, Xo (?), 00:08, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Пользователь ифон детектед)
     
  • 2.97, Оно ним (?), 09:42, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Пару месяцев назад купил бюджетный самсунг с 90 Гц - и ничего не выжирает. Спокойно держит сутки, а если игры не гонять, то и двое.
     
  • 2.163, Аноним (172), 10:41, 15/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Poco X3 NFC — среднебюджетник 2021 года, из коробки 120 Hz обновление экрана
    Poco M6 Pro — low-бюджетник 2024 года, из коробки 120 Hz обновление экрана

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

     

  • 1.39, Аноним (39), 20:30, 13/02/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Конфигурация с 1000Hz оказалась быстрее в тестах Llama.cpp, nginx, SuperTuxKart

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

     
     
  • 2.72, Аноним (69), 23:57, 13/02/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    линукс гейминг во всей красе)
     

  • 1.40, Аноним (40), 20:31, 13/02/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    И кто гуглу запрещает у себя в гугле 1000Hz поставить?
     
     
  • 2.46, Омнонном (?), 20:46, 13/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    А предлагатор сборку ядра не осилил пока ещё, только изменение кода.
     

  • 1.42, Аноним (42), 20:38, 13/02/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    А че не 1024? Там жеж, насколько я знаю, еще во времена каменного века на PC AT (на XT RTC был не обязательной железкой), RTC генерил IRQ 8 1024 раза в секунду и ниче. Все работало. Не тормозило.
     
     
  • 2.48, Аноним (-), 20:51, 13/02/2025 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > А че не 1024? Там жеж, насколько я знаю, еще во времена
    > каменного века на PC AT (на XT RTC был не обязательной
    > железкой), RTC генерил IRQ 8 1024 раза в секунду и ниче.
    > Все работало. Не тормозило.

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

     
     
  • 3.60, Ivan_83 (ok), 22:04, 13/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    HPET как раз не оч любят, типа оно на PCI шине и оверхэд большой, вот TSC типа где то прямо в проце без лишних шин посредине.
     
     
  • 4.103, Аноним (103), 11:04, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Казалось бы, кто мешает аппаратные таймеры юзать, на ходу меняя умножители как на том же STM8?
    Или слишком монолитно?

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

     
     
  • 5.132, Аноним (-), 15:57, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Слишком копролитно, x86-64 - это вам не оно, поэтому все оверинженернутее, навор... большой текст свёрнут, показать
     
  • 5.145, Аноним (136), 17:21, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    А если какой нибудь loop подвесится?
     
  • 4.131, Аноним (129), 15:53, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > HPET как раз не оч любят, типа оно на PCI шине и
    > оверхэд большой, вот TSC типа где то прямо в проце без
    > лишних шин посредине.

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

     
  • 3.106, Аноним (91), 11:30, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    HPET - давно превратился в рудименты. И все потому, что достаточно медленный. Проблема усугубляется, когда ядер в процессоре больше двух - тут производительность падает просто катастрофически.
     

  • 1.45, Омнонном (?), 20:45, 13/02/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Очередной хре с горы ниасилив решение своих задач, пытается решить их за счёт всех остальных.
     
  • 1.58, Ivan_83 (ok), 21:59, 13/02/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Фиговые инженегры у гугла, всякую чушь пишут.

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

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

     
     
  • 2.87, n00by (ok), 08:06, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Что бы повысить отзывчивость, достаточно уменьшать квант для "интерактивных потоков". Что делается в Виндос, а потому об этом говорить как бы неприлично. :)
     
     
  • 3.98, Ivan_83 (ok), 09:48, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А ты пойди найди на линухе такие процессы :)
    Это в венде с геум втащенным в ядро есть за что зацепится при поиске интерактивных.
    И насколько я понимаю там не уменьшение кванта времени а повышение приоритета.
     
     
  • 4.104, Аноним (103), 11:08, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Виндовый планировщик и в QoS умеет, чего уж там. Только в лучших традициях всё упирается в кривизну прикладного ПО.
    Причём после ухода Балмера даже родные тулзы делаются абы как и без учёта всего этого.
     
     
  • 5.133, Аноним (-), 16:00, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Виндовый планировщик и в QoS умеет, чего уж там. Только в лучших
    > традициях всё упирается в кривизну прикладного ПО.
    > Причём после ухода Балмера даже родные тулзы делаются абы как и без
    > учёта всего этого.

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

     
  • 4.125, n00by (ok), 15:29, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Да, там реализовано временным повышением приоритета. А как иначе? Два таймера - по каждому на свой тип потоков? Если правильно помню, выделялось по три кванта на поток, но повышенный динамический приоритет позволял влезть меж этими квантами вне очереди.
     
  • 2.94, Аноним (94), 09:33, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    весь проц должен отжирать шедуллер, а не ваши процессы! иначе не пойдёте покупать новый девайс
     

  • 1.63, Аноним (15), 22:28, 13/02/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Сомневаюсь что патч будет принят.
    Скорее Линус поржёт и закроет Юсуфу доступ.
     
  • 1.64, Аноним (64), 22:32, 13/02/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    А ведь это всё из-за Gnome, который лагает как какой нибудь смартфон Lenovo со вторым андроидом, не нужны нам эти "улучшения" на Openbox, тут и так всё работает отлично.
     
  • 1.67, th3m3 (ok), 23:20, 13/02/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Судя по тестам, лучше оставить как есть. Работает - не трогай!
     
     
  • 2.161, Аноним (172), 09:48, 15/02/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Хочу тебя расстроить, но «работает — не трогай» это очень плохой девиз придуманный в 90ые, когда для многих что-то настроенное было почти магией
    Если что-то работает, но можно улучшить, тем более если это что-то работает как сейчас просто в силу исторических причин, то можно и нужно менять

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

     
     
  • 3.171, th3m3 (ok), 22:34, 15/02/2025 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Тем более под твоей виндой

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

     
  • 3.177, Аноним (177), 08:54, 17/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > очень плохой девиз придуманный в 90ые

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

     

  • 1.68, Кроносквад128 (?), 23:30, 13/02/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Всё уже продумано в 5.6.0 эти только на этапе дао пути
     
  • 1.77, Балагур (?), 03:06, 14/02/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Инженеров linux у нас не осталось, судя по комментариям и самому посту. У нас уже тысячу лет в ядре вытесняющая многозадачность, а не кооперативная, да ещё и умная. Если процесс в течении своего тика делает sched_yield, а чаще всего он это делает, потому что 1/250 или даже 1/100 процессорного времени какого-нибудь i5 13500 - это слишком много тактов, то скидулер пускает следующий процесс.
     
     
  • 2.88, n00by (ok), 08:10, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    "Чаще всего делает" это из разряда "но у меня на виртуалке всё работает!"

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

     
     
  • 3.107, Балагур (?), 12:01, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Чаще всего делает, именно так, даже если ожидает I/O, то тоже делает, но косвенно. А приложения с бесконечным циклом мы в расчет не берём, все тяжёлые вычисления или на GPU, или распараллеливания, и в принципе, тяжёлые вычисления не критичны к тику, они критичны ко времени CPU.
     
     
  • 4.126, n00by (ok), 15:33, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Вспомнил, Минобразования рекламировал новую корочку диплома, там появилось "инженер". Надеюсь, им преподают теорвер и закон больших чисел в частности, а не только "циклы".
     
  • 4.150, Аноним (-), 19:17, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > все тяжёлые вычисления [...] не критичны к тику

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

     
  • 2.149, Аноним (-), 19:14, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Ты сейчас про average случай, но если мы говорим о латенси, то более уместно гов... большой текст свёрнут, показать
     

  • 1.82, Аноним (82), 06:29, 14/02/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А если собрать с HZ_10?
     
     
  • 2.134, Аноним (-), 16:02, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > А если собрать с HZ_10?

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

     

  • 1.137, Аноним (137), 16:46, 14/02/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Да сделайте уже частоту таймера динамической, пусть автоматически подстраивается под любую систему и её текущее состояние.
    Как и всё остальное, но это уже позже и железо поновее будет и технологии.
     
     
  • 2.142, Аноним (-), 17:09, 14/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    А на сколько стабильно от всех переключений будут работать подсистемы ядра?
     
     
  • 3.164, Аноним (137), 11:11, 15/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Автоматическая адаптация, адаптивная автоматизация.
    Адаптивная синхронизация...
     

  • 1.146, tim2k (ok), 17:56, 14/02/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    В FreeBSD с 13.1 kern.hz=1000
     
     
  • 2.157, sysop (?), 08:43, 15/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Получается, ОС для десктопа готова?
     
  • 2.176, Аноним (-), 23:19, 16/02/2025 [^] [^^] [^^^] [ответить]  
  • +/
    А ты 600 Hz (50*120)/10 ей выставить пробовал? Сюрпризы были? (не думаю что будут - я в далёком прошлом выставлял 120 с поллингом, и всё работало - это то-ли семёрка была, то-ли предрелизная бэта восьмёрки...)
     

  • 1.152, Аноним (152), 21:30, 14/02/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Все ж просто: посмотрите как сделано в нормальных юниксах современных - MacOS, iOS, iPadOS, tvOS - и сделайте так же. Но нет, пару гуглоидов будут до посинения меряться патчами в рассылке
     
     
  • 2.158, Аноним (-), 08:51, 15/02/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Все ж просто: посмотрите как сделано в нормальных юниксах современных - MacOS,
    > iOS, iPadOS, tvOS - и сделайте так же. Но нет, пару
    > гуглоидов будут до посинения меряться патчами в рассылке

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

     

  • 1.153, Аноним (153), 02:59, 15/02/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    А если в системе 32 потока? 32 задачи одновременно могут вообще ни с кем не бороться за ресурсы. Но опять же, если работающих задач в момент времени больше чем кол-во хардварных потоков, то оверхед гораздо меньше так как вычислительных ресурсов достаточно, чтобы это покрывать. По идее, если процесс все ещё требует ресурсов по окончанию кванта времени и при этом ещё есть свободные ресурсы для других задач - ему выделится сразу же следующий квант времени без переключения контекста, но, его выполнение будет прерываться чаще на 1000 "попросту", чем на тех же 250/300. Конечно, если запустить компиляцию в 32 потока, то скорей всего, десктоп на 1000hz будет более отзывчив, но не на столько, чтобы терять в производительности долгоиграющих задач.
     
  • 1.167, Jh (?), 18:44, 15/02/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    в генте это вообще не проблема, можно менять при каждой сборке ядра.
     
  • 1.175, Аноним (175), 20:12, 16/02/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    По идее, нужно посмотреть как меняется оптимальный интервал на каждом тике. Если он около такой же, то вполне можно предсказывать оптимальный интервал для следующего тика на каждом тике, а не лепить фиксированное значение.
     
  • 1.179, Аноним Нелюдимович (?), 17:44, 17/02/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    В патчах К. Коливаса это было уже лет 15 тому назад по умолчанию. Теперь и создатели ванили что-то такое поняли.
    ©"Горячие финские парни".
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



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

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