LINUX.ORG.RU

Вышел патчсет pf-kernel для Linux v3.2

 , ,


0

1

Доступен новый выпуск патчсета pf-kernel для свежего ядра Linux v3.2.

В патчсет входят:

  • стабилизационное обновление ядра до версии 3.2.1;
  • патчсет Кона Коливаса -ck с планировщиком процессов BFS;
  • обновленный планировщик ввода-вывода BFQ;
  • подсистема гибернации TuxOnIce;
  • файл конфигурации для ручной сборки ядра на ноутбуке Dell Inspiron 1525.

В патчсете пока отсутствует LinuxIMQ.

Скачать патч на ядро 3.2

>>> Официальный сайт

★★★★★

Последнее исправление: post-factum (всего исправлений: 1)
Ответ на: комментарий от anonymous

P.S. Как по мне планировщик BFS нет смысла втыкать. На глаз, как правило, разница не заметна, а если что автоматический renice делает свое дело.

Учитывая, что renice практически бесполезен на CFS, «своё дело» он не делает.

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

хз - но он очень древний
это говно просто вывешивает всю систему при своппинге
даже при отсутствии свопа оно это делает, чо уж там

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

Как писал выше, нагрузка на проц не повышается, остаётся такой, как была, но при этом фризы полусекундные есть. Когда нету работы со свопом всё летает.

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

1. Не вариант, т.к. ОЗУ 2Гб, и этого не всегда хватает на виртуалку с виндой или компиляцию самого же VirtualBox'а. 2. И что за вин-стайл?

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

Не помню по дефолту или нет (вроде как по дефолту в Десктопе), но у меня CONFIG_SCHED_AUTOGROUP включен.

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

Жирно здесь лишь твоё незнакомство с матчастью. В CFS nice влияет на пропорцию распределения времени между задачами разного приоритета. В BFS nice влияет на ожидаемый деадлайн выполнения задачи.

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

Я допустим очень удивился, когда во время компиляции с -j3 на двухядерке смотрел ещё хд-фильм и не было ни одного намёка на мини-фризы и подлагивания, хотя оба ядра были заняты на 100%, а от того же CFS иногда подлагивал

+1

Давно уже забыл про такое с BFS. Пересборка мира с -j3 никак не отражается на отзывчивости системы

partyzan ★★★
()
Ответ на: комментарий от post-factum

Ну так я ж и сказал ему, что жирно.

Мы же говорим о ПК с 2-мя (максимум 4-мя ядрами). И с 1-10 реально нуждающимся в просессорном времени нитями.

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

anonymous
()

Как я могу беспроблемно накатить данный патч в openSUSE? Толковый гайд бы, так как готовых пакетов нету.

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

В CFS nice влияет на пропорцию распределения времени между задачами разного приоритета.

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

Ваш К. О.

P.S. Ну да, мы же знаем что ЛОРовци будь они даже школьниками считают себя умнее разработчиков Ядра. :)

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

Будь добрым, скажи пути конфигов, или ссылочку на русском. Я с этими параметрами не связывался.(Calculate - Gentoo).

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

Именно поэтому процесс с большим приоритетом выполнит большее число операций за некоторый промежуток времени чем другой процесс имеющий меньший приоритет за тот же промежуток времени.

Если у тебя запущен 1 mplayer, торрент-качалка, пара архиваторов и 4 gcc, то тебе, чтобы нормально смотреть кины, не важно, что «процесс с большим приоритетом выполнит большее число операций за некоторый промежуток времени». Тебе важно, чтобы mplayer, выходя из состояния ожидания, имел абсолютный приоритет над остальными претендентами на CPU.

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

Если у тебя запущен 1 mplayer, торрент-качалка,...

Вот видеш, у тебя уже появляется понимание работы планировщинка.

Уже ж не тупой троллинг:

Учитывая, что renice практически бесполезен на CFS, «своё дело» он не делает.

И это хорошо. :)

Теперь по теме: если время распределяется не по процессам, а групам процессов, значит 4 gcc, будут групой, пара архиваторов вероятно тоже. Вон товарищ кинул ссылку, хорошую. Нужно быть чесным, те проблемы о которых ты говорил провляються только при >50 высоконагруженных процессов на ядро, в противном случае renice Работает!!!

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

anonymous
()
Ответ на: комментарий от post-factum

Флешка же запилится быстро. flush чуть лучше.

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

Нужно быть чесным, те проблемы о которых ты говорил провляються только при >50 высоконагруженных процессов на ядро, в противном случае renice Работает!!!

Действительно, нужно быть честным, и ссылаться на факты. На однопроцессорной машине достаточно запустить 5-6 процессов с бесконечными циклами, чтобы время отклика иксовых приложений ощутимо вышло за пороги комфортности. В реальности же достаточно единственного gcc, чтобы мышь начала ходить рывками. А 3 восклицательных знака не помогут.

группам

Группы — отличный механизм для сервера. На десктопе же никто не будет париться с расскидыванием процессов в группы, если можно просто сменить планировщик.

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

В случае процессов, дающих одинаковую (непрерывную) нагрузку, никакого отличия от CFS не будет. Оба процесса просто получат максимальные виртуальные деадлайны, и время между ними будет распределяться поровну.

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

Вообще же, описывать систему, в которое критично _время_ _отклика_ в терминах _пропорций_ распределения времени — это принципиальная ошибка. Сколько с cgroups не танцуй, это не изменит того, что сам подход в корне ошибочен.

geekless ★★
()
Ответ на: комментарий от skai-falkorr

skai-falkorr

обновил инструкцию в блоге^_^

О, скай, за это вот спасибо. И как, уже попробовал? Всё работает без заморочек?

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

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

Так и должно быть. Разные процессоры имеют разную скорость обработки данных. Как не крути, а если на однопроцессорной машине запустить два процесса с бесконечными циклами, то они будут работать медленней чем каждый по отдельности. Ну это так, основы информатики :)

Еще раз: твой вброс, о том, что «renice практически бесполезен на CFS», надеюсь был тупым троллингом, а не просто глупостью.

По остольному, я вобщем то и не спорил. На обычном десктопе с иногда 1-5-мя непрерывно грузящими систему процессами BFS дает лучшую отзывчивость чем CFS без автогруппирования и авто renice-а.

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

Никто его не выкидывал. Его в pf-kernel не было.

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

Действительно, ложная тревога, в PKGBUILD он есть. Прошу прощения.

ValdikSS ★★★★★
()

Странно. Не собрался ERROR: «freeze_kernel_threads» [kernel/power/tuxonice_core.ko] undefined! ERROR: «in_suspend» [kernel/power/tuxonice_core.ko] undefined!

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

Настройки не менялись, TuxOnIce не пользуюсь. Собираю заново без него.

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

Поставил как в том посте swappiness = 100. При мелких сбросах вроде даже неплохо ведёт, но когда сбросить нужно поприличнее, то был просто ад: в течение минуты были 10-15 секундные фризы. После - более-менее... Но когда надо запустить (попробовал на LO Writer'e) пришлось ждать полминуты. Так что это тоже не панацея.

Demacr ★★
()

Поставил 3.2.1-pf. Полёт пока стабильный, но при запуске, gdm взлетал дольше обычного раза в 2-3.

Demacr ★★
()

«В патчсете пока отсутствует LinuxIMQ.»

Маэстро в 2 словах, что это? Страницу проекта я не распарсил.

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