LINUX.ORG.RU

Для ядра Linux написан патч, многократно улучшающий отзывчивость системы

 


0

5

Майк Галбрейт (Mike Galbraith) написал патч, многократно улучшающий отзывчивость системы при использовании многопоточных фоновых приложений, таких как, например, компиляции. Линус Торвальдс проверил и высоко оценил данную работу. К примеру, он запустил сборку — 'make -j64' — и при этом система оставалась отзывчивой, а прокрутка в веб-браузере — плавной. Торвальдс прокомментировал патч так: «that's a killer feature».

>>> Подробности

★★★★★

Проверено: svu ()
Последнее исправление: Dendy (всего исправлений: 1)

Херня кажись. Просто вброс.

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

>Даешь в мейнстриме разделение на desktop & server ядра?

В бубунте есть (всмысле параметров при компиляции), правда там нет workstation ядер (linux-rt уже не компилят).

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

> равномерно растущие счетчики в /proc/interrupts во время тормозов

Равномерно или не равномерно (по ядрам)?

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

>>Старый прикол с «dd if=/dev/zero of=file bs=2G» уже нифига не работает

Чудес не бывает. Значит у тебя упала скорость IO, и вместо того, чтобы заниматься делом (dd) система обслуживает туеву хучу фоновых процессов типа всяких иконок в трее. Тут одно из двух, либо они у тебя не высвапливаются в обмен на место для буферов, либо планировщик успевает их «справедливо» обслужить.


А вот и хрен. Скорость dd практически не изменилась.

З.Ы. Жду изю в треде с объяснениями, почему бздю не надо закапывать.

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

Грузить нолики лопатой это канешн дело.

Для десктопа - охренетительно, на самом деле.

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

>>Старый прикол с «dd if=/dev/zero of=file bs=2G» уже нифига не работает

Чудес не бывает. Значит у тебя упала скорость IO, и вместо того, чтобы заниматься >делом (dd) система обслуживает туеву хучу фоновых процессов типа всяких иконок >в трее. Тут одно из двух, либо они у тебя не высвапливаются в обмен на место для >буферов, либо планировщик успевает их «справедливо» обслужить.

не-не-не
со скоростью как раз всё в порядке

megabaks ★★★★
()

Наконец-то ! Это был единственный недостаток линукса в сравнении с BSD и Solaris.

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

>Хотя, файрфокс как задумывался, так и задумывается.
Это i/o тормоза, а не тормоза процессора, патч тут не поможет. Лечится переездом .mozilla в память или выкидыванием файрфокса

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

Это просто файрфокс. Надеюсь что 4я версия будет такой же киллерфичей, хаха.

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

с утра накотил патч...

накоДил? накАтил? накошмарил? накотовасил?


наКОТил! ( чо, спелчеккер ругается ? :) )

сильно не красноглазил, погонял в обычном режиме систему - отличий особых не заметил. т.е. система и раньше не страдала тормозами : видео смотрю через vdpau, ядро с PREEMPT_RCU и CONFIG_HZ=1000, проц с 3мя ядрами, ткчто спокойно мог компилять и смотреть HD видео по сетке . не в 64 потока конечно, но все-же.

правда заметно выросла нагрузка на проц.

anTaRes ★★★★
()

Придётся ждать бэкпорта на 2.6.32((( из экспериментальной ветки ядро ставить как-то не хочется

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

Ща лор роделится на тех кто на 35 36 37 и радуются мегаускорению просмотра башорга и тех кто ноет что силят на 30 31 32 и оно туда не впиливается.

Руками патч накатить не пробовал? У меня только так и воткнулся.

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

> Кто бы хоть озвучил, какого саботажника это был код который так тормозил ядро что понадобилось этот саботаж переписывать?

Присоединяюсь к вопросу. Линуксоиды должны знать своих героев.

«Имя, сестра, имя!» (с)

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

> Как выросла?

ну, допустим есть некий процесс, который при запуске стабильно отъедает 30%. теперь - 40-45%%

но это также может быть связано с самим ядром (было 2.6.36, собрал с патчем 2.6.37-rc2), или обновлениями (крутил все ручки сразу).

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

Допустим те же кто делали поддержку 2048 квантовых процессоров и прочие серверные фичечки.

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

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

Присоединяюсь к вопросу. Линуксоиды должны знать своих героев.

«Имя, сестра, имя!» (с)

Сабжевый патч ничего не исправляет. Он просто добавляет автоматику, которая сама раскидывает процессы в разные cgroups'ы по привязке к tty.

Deleted
()

Кажется патч нужен только тем, кто что-то конпелирует на фоне. Круто, конечно, но всё же хотелось бы взглянуть на реализацию, не привязанную к tty.

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

Кажется патч нужен только тем, кто что-то конпелирует на фоне. Круто, конечно, но всё же хотелось бы взглянуть на реализацию, не привязанную к tty.


или тем кто вываливается в свап. или тем у кого на беграунде VirtualBox. или тем у кого kde и висит куча vistuoso/nepomuk etc.

не привязанную к tty? brainfuck scheduler.

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

> This «users are idiots, and are confused by functionality» mentality of Gnome is a disease. If you think your users are idiots, only idiots will use it.

Огромный рынок, судя по венде-варде.

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

>про server ядра помню только то что паникуют и косячат по сравнению со штатным debian. может, давно не пробовал.

Сейчас нормально работают. Единственный минус при установке новых ядер не запускается update-grub. В итоге сервер ложится после перезагрузки. Лечится выпиливанием update-grub и ручным прописыванием boot /vmlinuz & boot /vmlinux.old в grub.conf.

anonymous
()

Гм. Что-то я ничего не заметил на 35-ом ядре (правда, накладывал не на ванильное, но патч встал). Эксперименты с dd на глаз не различаются при разных значениях kernel.sched_autogroup_enabled. Опыты с Виртуалбоксом все так же фризят все нахрен. Надо вечером еще покопаться.

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

> Эм. А загрузка процессора в линуксе процентами меряется? Это как?
> Load average изменилось?

это gkrellm висит в углу экрана, показывает мини-топ и загрузку в процентах :)

еще работает ondemand-scheduller , который (вроде) переключает состояния в зависимости от такой загрузки.
подумалось что для нотиков сомнительная фича (battery killer feature)

powertop нужно погонять чтоб точно сказать, я ж ничего не замерял - просто «на глаз» оценил.

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

Гм. Что-то я ничего не заметил на 35-ом ядре (правда, накладывал не на ванильное, но патч встал). Эксперименты с dd на глаз не различаются при разных значениях kernel.sched_autogroup_enabled. Опыты с Виртуалбоксом все так же фризят все нахрен. Надо вечером еще покопаться.


во-первых можно что-то компилить на беграунде (сильно заметно отличие как компилил ядро до и после, после можно было параллельно что-то делать)
во-вторых, система живее вытряхивается со свапа.
в-третьих, система нахрен вешалась после 3го виртуалбокса с tinyXp, сейчас с 6ю наглухо свапуется, но работать можно

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

> Гнум целится на место винды во всех смыслах?

Увы.

А впрочем пох.

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

>Сейчас нормально работают. Единственный минус при установке новых ядер не запускается update-grub. В итоге сервер ложится после перезагрузки. Лечится выпиливанием update-grub и ручным прописыванием boot /vmlinuz & boot /vmlinux.old в grub.conf.

Кажись есть места, куда можно засунуть хук, чтобы вызывался update-grub.

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

во-первых можно что-то компилить на беграунде (сильно заметно отличие как компилил ядро до и после, после можно было параллельно что-то делать)


у меня и без патча так можно.

во-вторых, система живее вытряхивается со свапа.

в-третьих, система нахрен вешалась после 3го виртуалбокса с tinyXp, сейчас с 6ю наглухо свапуется, но работать можно


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

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

> Кажись есть места, куда можно засунуть хук, чтобы вызывался update-grub.

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

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

>так с сабжем bfs не нужен, даже -j 128 (LA за сотку) ничего не тормозит

Ты уверен что бфс не нужен? Тут же привязка к tty. Запусти рекодинг в x264 в avidemux , какой-нить гуи плейер с hd и т.д. Или ты думаешь, что все на _ДЕСКТОПАХ_ исключительно компилят и обязательно в 64+ потока?

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

>[fat] Надо просто каждую программу запускать из отдельного окна эмулятора терминала. Делов-то! [/fat]

Тогда я не понимаю в чем этот 200 строк такие класные или почему во всех новостях про патч упоминается десктоп. Наверное имелся в виду десктоп Линуса ,на котором только и делается - что компилится.

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

> Запустил. Завтра устрою virtualbox + make -j4 + cp.

Мне кажется это плохой тест. В заголовке упоминается десктоп. Виртуальная машина, сборка в 4 потока и зачем-то cp - не такие уж десктопные задачи имхо.

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

>> не привязанную к tty? brainfuck scheduler.

И systemd тоже.

о_О а с каких это пор мозготрах-планировщик привязан к поделке?

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

отсыпь, а?
какое отношение мозготрах-планировщик имеет к systemd?
он вообще то был за долго до появления этого велика

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

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

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

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

>Кажись есть места, куда можно засунуть хук, чтобы вызывался update-grub.

А без него намного приятнее стало. Новое ядро линкует себя в /vmlinuz, а старое перелинкует в /vmlinuz.old. А конфиг груба я предпочитаю сам редактировать.

Совсем offtop: конфиг груба по дефолту в бунте - самое глупое, что есть в дистрибутивах :) Вчера обновил ядро с этим патчем. Забыл создать initrd.img. Ядро в ужасе и панике. А со старым ядром я не могу загрузиться. По дефолту меню в грубе скрыто, а зажатый Shift на usb клавиатуре это меню не открывает (на чём они тестят свои системы?). Как дурак, ночью продирался в другую комнату, чтобы взять ps/2 клавиатуру :)

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

# X в CONCURRENCY_LEVEL - это количество процессоров или ядер, которое у вас есть, для ускорения сборки. INSTALL_MOD_STRIP=1 CONCURRENCY_LEVEL=X fakeroot make-kpkg --initrd kernel_image kernel_headers cd .. && dpkg -i *.deb

так у тебя будет инитрд + белый и пушистый груб :)

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

>Если эта плата в небольшом замедлении вычислительных операций — я на это согласен.

Крайне сложный вопрос. Его нужно как-то тестировать. То, что скорость IO упала, это сомнений не вызывает. Вопрос на сколько.

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

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