LINUX.ORG.RU

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

 


0

5

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

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

★★★★★

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

А тем временем, в devel рассылке федоры Lennart говорит что патч этот зря биндит на TTY и в systemd будет нечто похожее.

DukE-M ★★
()

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

Legioner ★★★★★
()

> и при этом система оставалась отзывчивой, а прокрутка в веб-браузере — плавной.

[trollmode]Так и запишем, что у Линуса наконец-то перестал тормозить Хром[\trollmode]

DukE-M ★★
()
Ответ на: комментарий от kernelpanic

Ну так у меня через DVI и D-Sub тоже нормально :)

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

Спасибо, отличная ссылка!

CPU Value (CPU Mark / $Price )
Higher results represent better value

http://www.cpubenchmark.net/cpu.php?cpu=Intel+Celeron+E3300+%40+2.50GHz
AMD Phenom II X6 1055T   28.97
Intel Celeron E3300 @ 2.50GHz   35.38
Intel Core i7 950 @ 3.07GHz   21.39
Intel Core2 Quad Q9650 @ 3.00GHz   13.37
Intel Core i7 980X @ 3.33GHz   10.39

Походу я выбрал отличный процессор.

queen3 ★★★★★
()

Сижу сейчас под пропатченым ядром. Явно вижу вендекапец.. Старый прикол с «dd if=/dev/zero of=file bs=2G» уже нифига не работает - FF вообще не тормозит. Жесть.

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

> Интересно когда сей патч попадет в ядро debian unstable. На данный момент там Linux laptop 2.6.32-5 ... До .36 или .37 еще далеко :(

Unstable разморозится после релиза squeeze. Но на самом деле 2.6.36 есть в experimental.

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

> Unstable разморозится после релиза squeeze. Но на самом деле 2.6.36 есть в experimental.

Анонимус подтвердит в этой ветке когда в experimental добавят этот патч? Ну пожалуйста... :)

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

>А в 20 потоков?

А толку? Ядро-то одно.

А по факту. Компилил одновременно два проекта (mplayer и kernel) и смотрел фильм/играл в q3. Все шло на Ура. Так что не надо тут.

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

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

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

Но нужно тестировать, конечно...

Например, у меня система запущенная с make -J после того как пожрет все 8 гигов памяти встает колом из-за битвы за свап. Но например, создание образов DVD из файлов на диске, на работу системы не влияют никак.

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

Осталось сравнить теперь какой оверхед от данной фичи.

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

>> Unstable разморозится после релиза squeeze. Но на самом деле 2.6.36 есть в experimental.

Анонимус подтвердит в этой ветке когда в experimental добавят этот патч? Ну пожалуйста... :)

Думаю, в этой рассылке смогут подтвердить: debian-kernel@lists.debian.org

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

Делал wake-up виртуалке, а это — практически линейное чтение снепшота с диска. Так вот, скорость просыпания осталась на прежнем уровне или даже немного увеличилась, а вот отзывчивость явно стала много лучше.

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

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

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

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

>Кто-нибудь накладывал патч на ядро 2.6.35-7? Удалось ли? И если удалось, то что проделывали, чтобы заработало?

Накладывал на ванильное 2.6.35.8. Потч матюкнулся только на kernel/sched.c
Открываем его, дописываем где-то сначала: #include «sched_autogroup.h»
Компиляем, радуемся жизни...

З.Ы: Пробовал накатить на 2.6.35-zen2. Пофиксил некоторые реджекты, сами сиходники скомпилились нормально, но ядро не слинковалось. Видимо таки да, патч BFS там что-то существенно поменял. Разбираться и допиливать лень...

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

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

у меня был атлон 64 3000+ и видюха гф 7600 гт, сейчас шестиядерник феном и встроенная видео 4290а - так вот комп с шестиядерником суммарно меньше шрёт энергии, проц при нашрузках игонда до 40 градусов нагревается

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

да кстати на атлоне стоит бп на 500 ват, а шестиядернику хватает 400

anonymous
()

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

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

есть неприятные моменты
вот лью большой торрент - скорость несколько метров в сек
таки плеер один раз на долю секунды заикнулся
интерактив тоже бывает дёргается, но несильно
огромный плюс - нету фризов
ещё бы с bfs подружить для интерактива и было бы совсем хорошо...

megabaks ★★★★
()

Когда и во что его запилят?

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

>А к чему все Коливаса вспоминают? Он же планировщик i/o писал, а не многозадачности.

ЩИТО? Его BFS - это вообще-то планировщик задач. Не путать с BFQ (планировщий I/O).

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

>А к чему все Коливаса вспоминают?
во-первых его bfs с прицелом на отзывчивость фейса
во-вторых сабж не дружит с bfs - либо не работает bfs либо ломают нахрен ядро до несобираемого состояния

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

>у меня был атлон 64 3000+ и видюха гф 7600 гт, сейчас шестиядерник феном и встроенная видео 4290а - так вот комп с шестиядерником суммарно меньше шрёт энергии, проц при нашрузках игонда до 40 градусов нагревается

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

да кстати на атлоне стоит бп на 500 ват, а шестиядернику хватает 400

Так ведь не ясна объективная картина исходя из таких измерений, дутые там показатели экономичности на максимальной мощности или нет. Может проц понижает свою мощность на пиковых нагрузках чтобы не расплавиться и не остаться без питания. У меня тоже, на двух ядрах видуха не перегревается а проц почти всегда в норме. Но иногда случаются пиковые нагрузки при сборке или в играх кингс боунти и герои мальгримии. Тогда теплоотдача зашкаливает, но если бы проц был чуть слабее, то всё равно справился бы с этими задачами))) Заметил, 100% нагрузка ядер не показатель, в одних случаях температура держится в норме а в других нет.

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

Napilnik ★★★★★
()

После патча amule стал устраивать дикие тормоза. Стоят настройки сворачиваться в трей и после запуска тоже туда сворачиваться, окно больное, на весь экран. После включения это окно моргает как светомузыка.

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

во-первых его bfs с прицелом на отзывчивость фейса


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

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

>так с сабжем bfs не нужен
а вот и нет :)
нужен и ещё как

megabaks ★★★★
()

от ck практически никакой разницы с ванильным ядром было не видно, здесь же сразу же результат :)

Няшку создателю патча !

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

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

Так в этом и есть многозадачность, не?

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

зато при отсутствии bfs ох как не хватает его :3

megabaks ★★★★
()

А тем временем в РедХат....

«This appears completely backwards to me. Attaching things like this to a TTY is just wrong, because normally we don't have a single TTY around on most graphical sessions.

The kernel doesn't really have a notion of what a „session“ is (only the audit subsystem kinda has), but if this grouping behaviour is supposed to be bound to a session, then attaching it to a TTY is a pretty shitty replacement.

Dhaval Giani pointed out to me that the same can be done from userspace simply by creating a cgroup for each session in the cpu hierarchy. Turns out systemd actually does pretty much that, except in the named systemd hierarchy. It is trivial modification to create a group in both hierarchies.

Lennart Poettering»

«Мне это кажется шагом назад. Привязка подобных вещей к TTY просто глупость - в графических сессиях у нас может быть ни одного TTY.

Ядру вообще до лампочки все эти „сессии“ (разве что подсистема аудита может что-то знать), но если групповое поведение должно быть привязано к сессии, то привязка к TTY - это говённое решение.

Dhaval Giani подсказал, что тот же эффект можно получить из юзерспейса обычным созданием cgroup для каждой сессии в ирерархии процессора(?). Выключение systemd делает почти то же самое, но в именованной иерархии systemd. Создание группы в обеих иерархиях - это ж как два пальца обоссать!

Lennart Poettering»

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

>Няшку создателю патча !

Лучше шоколадку ему подари!

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

ну попробуй прикрути к 32-ому, ога ^_^
там или полпатча переписывать...или ядро
просто посмотри на сорсы и на патч - потом скажи тому народу...ну ты понел

megabaks ★★★★
()

С утра накатил патч - день свободен!...

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

Но в искажении трактовки гномоHIGa его особо не упрекнешь, правда? И вернулся он не из-за выдержки, а из-за KDE 4.0, продолжая питать те же чувства к гнуму. А кеды уже снова торт ;)

anonymous
()
Ответ на: А тем временем в РедХат.... от matumba

То есть, к софту, запущенному не из tty, это не относится? Он так же будет продолжать насиловать систему как и раньше?

pevzi ★★★★★
()

Патч разделяет процессы на группы (используя cgroups) в зависимости от tty. По-моему, этой задаче место в юзерспейсе. systemd, например, уже использует cgroups для управления демонами. Почему бы не переложить на него же и заботы по установке приоритетов для разных групп? Плюс сделать некую утилиту для управления группами и приоритетами (напрямую через файловую систему это таки не очень удобно). Я считаю, это было бы более гибкое решение.

Хотя, systemd когда ещё будет, а патч уже есть и уже работает, за что автору спасибо.

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

>Спрашую громче, как это сделать?!

Не, народ сказал, что там пол патча переписывать или пол ядра... В таком случае, только накатывать :)

anonymous
()

Накатан ручками на бубунтовский 35.

На удивление, на Core 2 с -j 32 окошки даже переключаются. Принудительный загон системы в swap тоже не помог. Три сессии 4х кед заставили немного притормаживать. Прикольненько.

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

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