У меня сложилось впечатление, что патч (в деталях описывается большинство деталей о нем) заключался в том, что он может более равномерно сбалансировать пропорции процессора в автоматическом режиме.
Планировщик Linux CFS полностью честный некоторое время занимался балансировкой групп. Это означает, что если пользователь A запускает 500 задач, а пользователь B запускает только одну, справедливость должна балансировать между пользователями , а не задачами.
С этой целью все задания пользователя A должны быть в одной группе, а все задания пользователя B - в другой, а ЦП будет распределен поровну между ними - пользователь A не получит больше емкости только потому, что он анти-социально запущенные задачи.
Однако справедливость основывалась либо на идентификаторе пользователя (динамическом), либо на контрольных группах (относительно болезненный, статический метод настройки).
Похоже, что этот патч выполняет автоматическое распределение заданий группе на основе их TTY. Таким образом, разделение на группы становится автоматической функцией (без настройки групп управления), и она происходит с более мелкой гранью, чем идентификатор пользователя (поскольку на типичных рабочих столах только имеет один пользователь, выполняющий большинство заданий По крайней мере, не-администраторские).
Итак, когда Линус садится за компиляцию следующего ядра для нас, процесс массивной параллельной сборки объединяет все свои задачи в одну группу, и тогда Линус может запустить VLC, чтобы посмотреть последний эпизод Теория большого взрыва. (Понятия не имею, смотрит ли он это шоу, и не имеет ли он на своем компьютере различного программного обеспечения, насколько я знаю, он может запускать Windows Media Player под Windows 7) в совершенно отдельной группе.
Тогда ЦП будет относительно равномерно распределен между двумя группами , и Линусу не придется смотреть, как Шелдон рывками движется по экрану.
Конечно, это замедлит сборку ядра, но это не так, как будто это важная задача, которую он выполняет для нас. Мы можем немного подождать, если это означает, что его уровни вменяемости поддерживаются: -)
Из того, что я прочитал (и увидел), этот значительно улучшает скорость отклика настольных приложений. Он не дает вам большей общей емкости, но в определенных сценариях он значительно улучшает ситуацию.
Конечно, если ваш профиль использования - одна задача на TTY (или все задачи в одном TTY), это, вероятно, не сильно поможет. Но если это улучшит некоторые сценарии и не ухудшит слишком много других, это будет победителем. И, даже если он действительно ухудшает качество других, это настраиваемое поведение, поэтому он, вероятно, все равно проникнет в ядро.
Интересно, что теперь, когда этот кандидат на патч вышел из «основного СМИ», из дерева выходят люди, заявляющие, что вы можете сделать то же самое с модификациями вашего .bashrc и некоторых других мелких подстройка. Это в основном оборачивает «автоматизированный» инструмент вокруг контрольных групп, о которых я упоминал ранее.
Линус уже отклонил это решение для пользователей, так как хочет, чтобы оно не зависело от оболочки, и пользователям это не нужно делать:
Потому что это то, что мы хотим сделать для всех пользователей и для всех оболочек, и убедиться, что это делается автоматически. В том числе для пользователей, у которых есть старые дистрибутивы и т. Д., И которые легко сделать в одном месте. И затем вы делаете это для всех других эвристик, которые мы можем легко увидеть в ядре. И затем вы делаете это волшебным образом, без пользователей, даже если вы заметили .
Вдруг уже не так уж приятно играть с bashrc, не так ли?
В этом все дело. Мы можем вытолкнуть изменение ядра, и все будет «просто работать». Мы можем сделать эту функцию, которая уже есть в ядре, на самом деле полезной .
Конфигурация на уровне пользователя для чего-то, что должно просто работать, раздражает. Мы можем сделать лучше.
Другими словами: если мы найдем лучший способ сделать что-то, мы должны не сказать: «Ну, если пользователи этого хотят, они могут сделать это <техническую вещь здесь>». Если это действительно лучший способ сделать что-то, мы должны просто сделать это. Требуется пользовательская настройка , а не функция.
Теперь я не говорю, что мы не должны позволять пользователям использовать cgroups. Конечно, они могут делать вещи и вручную. Но мы не должны требовать от пользователей делать глупости, которые мы могли бы легче делать сами.
Если выбор между тем, чтобы сказать всем: «ты должен это сделать», и «мы должны просто сделать это для тебя», я выберу второй вариант каждый раз. Мы знаем, что это должно быть сделано. Почему тогда мы должны сказать кому-то другому сделать это для нас?
Я должен согласиться с этим мнением - если бы вам было позволено сказать пользователю, что он должен сделать что-то особенное для повышения производительности, вы могли бы просто заставить его использовать "nice make -j64" вместо "make -j64".