В списке рассылки разработчиков Linux-ядра представлено (http://permalink.gmane.org/gmane.linux.kernel/1085285) системное приложение ulatencyd (https://github.com/poelzi/ulatencyd/), меняющее в фоновом режиме параметры планировщика задач (через манипуляцию с cgroups, nice, ionice и т.п.) и другие характеристики Linux-ядра, динамически подгоняя их для обеспечения максимальной отзывчивости десктоп-системы.
Параметры работы ulatencyd задаются через правила, оформленные в виде скриптов на языке Lua (непосредственно демон написан на Си), поэтому пользователь легко может изменить поведение и реализовывать собственные методы тюнинга. Для сбора информации о состоянии процессов используются (https://github.com/poelzi/ulatencyd/raw/master/docs/architec...) данные из файловой системы proc, интерфейса netlink и встроенной в ядро системы аудита. При росте нагрузки со стороны отдельных процессов демон на основании определенных на языке Lua правил принимает решение об ужесточении лимитов ...URL: http://permalink.gmane.org/gmane.linux.kernel/1085285
Новость: http://www.opennet.me/opennews/art.shtml?num=29259
Больше программ хороших и разных
и что характерно, главное начать: сначала решили подобное в ядре, и теперь люди тут же написали/додумали новое в юзерспейсе! это очень здорово.
(хмыкаю) Лучше меньше да лучше (С) В.И. Ленин.
Радуют сдвиги в верном направлении, не радует что для этого потребовалось 20 лет, и до сих пор далеко не все разработчики осознают значимость отзывчивости десктопа, а ведь это важнейший параметр.
> не все разработчики осознают значимость отзывчивости десктопаМожет потому, что она не очень значима? Ведь это удобство, не более того.
>Ведь это удобство, не более того.На десктопе именно это и есть самое главное. Я не могу работать, когда все лагает и тормозит. Пользователю как правило плевать на то, что какой-нибудь gzip упакует 8Гб на 5 секунд медленней, а вот если во время той же упаковки ничего больше делать невозможно, то это уже очень сильно раздражает.
Кстати, это прекрасная иллюстрация технократического образа мышления, в котором на первое место ставится не человек а машина. Пару лет назад создавалось впечатление, что Con Kolivas был единственным разработчиком, который заботился о простых юзерах)
значима!
Если лет 5 назад ещё можно было поспорить, то сейчас линукс на десктопе довольно обыденное дело, а если учесть всякие гаджеты то и подавно.
линукс на десктопе обычное дело? мои тапочки плакали.
а что такого?
1% - это обыденное дело?
Вам тут ниже ответили. Мне кажется и одного процента даже нету, потому что гиков не так много. Я не знаю ни одного человека кроме себя, и не программиста, который бы юзал линукс.
Я знаю достаточно(около 15) людей уровня "продвинутый пользователь" которые пользуют(на работе и дома) убунту (реже другие дистры) и в целом выглядят более довольными чем на венде, хотя конечно не всё идеально.p.s.
Заметил большинству таких людей за 30, видать опыт(и лень) берёт своё :)
а насчет статистики 1%, она несколько исскуственна, и насчет неё можно вечно спорить,
имхо - сейчас реально где-то около 5% и растёт
Вы так говорите, будто для сервера отзывчивость не нужна...
> Вы так говорите, будто для сервера отзывчивость не нужна...Нужна, конечно. Кстати, никто не в курсе, как запретить вытеснять страницы приложений в своп при наличии свободной памяти? Это тоже очень влияет на интерактивность. Установка vm.swappiness в 0 не помогает.
>Нужна, конечно. Кстати, никто не в курсе, как запретить вытеснять страницы приложений в своп при наличии свободной памяти? Это тоже очень влияет на интерактивность. Установка vm.swappiness в 0 не помогает.Ага, и получить отсутствие дискового кэша и продолжительный выгруз в свуп, если память все же кому-то понадобится. Тут тонкий момент, надо думать.
По сабжу - там константа + swappines, наверное, только патчить. Я бы не стал. ;)
Я тоже думал над этим, прочитал несколько срачей разработчиков по этому поводу и решил, что лучше для меня отключить. Потому что происходит вот что: у меня комп включен постоянно, раздает сразу много торрентов, фтп и пр. все это не жрет особо много ресурсов, но держит открытыми кучу файлов. При этом запущен фаерфокс, который занимает 200-300 метров памяти и никуда не обращается в простое, в отличие от торрентов, поэтому постепенно вытесняется в своп со многими другими приложениями. Ну и вот я прихожу домой, дергаю мышкой и примерно 1-2 минуты(!) наслаждаюсь скрежетом диска и полностью зависшим гуем.
Дело в том, что если память кончается, то тормоза неизбежны в любом случае и при любой политике свопа, но это ожидаемое поведение. А вот то, что при наличии кучи свободной памяти и всего прочего начинаются адовые тормоза очевидно неправильно. И уж совсем неправильно не давать пользователю это поменять - к вопросу о технократическом подходе.
а не пробовали не монтировать swap? Тоже интересно чем дело закончится. :)
> а не пробовали не монтировать swap? Тоже интересно чем дело закончится. :)Пробовал, но у меня всего 1 Гб памяти, иногда(очень редко) ее действительно не хватает. Да и не спортивно это, своп отключать.
>Дело в том, что если память кончается, то тормоза неизбежны в любом случае и при любой политике свопаНихт. В том-то вся и суть.
>А вот то, что при наличии кучи свободной памяти и всего прочего начинаются адовые тормоза очевидно неправильно.Видимо, что-то точно не свободно, особенно ежель 1-2 минуты. ;) Диск?
>И уж совсем неправильно не давать пользователю это поменять - к вопросу о технократическом подходе.
Ну да, теперь у нас есть надежда на сабж (ulatencyd) %) Либо ручками ionice и иже с ним.
> поэтому постепенно вытесняется в своп со многими другими приложениями.
> Ну и вот я прихожу домой, дергаю мышкой и примерно 1-2 минуты(!)Практически 1:1 напоминает описание дёрганья мышкой под AIX лет десять тому. :) Доросли...
А, вот: http://tinyurl.com/frl-aix-swap
Так о том и речь, что может быть при некоторых условиях это и правильно (хотя я не разделяю мнения о том, что память должна быть использована целиком ценой таких жертв), но на десктопе уж точно должна быть возможность изменить такую политику и вообще упор надо делать на интерактивность. Хорошо что хоть кто-то этим занимается, потому что ситуация действительно нездоровая.
> Ну и
> вот я прихожу домой, дергаю мышкой и примерно 1-2 минуты(!) наслаждаюсь
> скрежетом диска и полностью зависшим гуем.Ubuntu 10.04 i386, 1 Gb RAM, Gnome, transmission.
Swap подключен и не используется. Никаких тормозов не наблюдаю после долгого "простоя"
(работает круглосуточно неделями).
>.... никто не в курсе, как запретить вытеснять страницы приложений в своп
#include <sys/resource.h>
/* ... */
struct rlimit limit;
limit.rlim_cur = 0;
limit.rlim_max = 0;
if (setrlimit(RLIMIT_CORE, &limit) != 0) {
/* Handle error */
}long pagesize = sysconf(_SC_PAGESIZE);
if (pagesize == -1) {
/* Handle error */
}char *secret_buf;
char *secret;secret_buf = (char *)malloc(size+1+pagesize);
if (!secret_buf) {
/* Handle error */
}/* mlock() may require that the address is a multiple of PAGESIZE */
secret = (char *)((((intptr_t)secret_buf + pagesize - 1) / pagesize) * pagesize);if (mlock(secret, size+1) != 0) {
/* Handle error */
}/* Perform operations using secret... */
if (munlock(secret, size+1) != 0) {
/* Handle error */
}
secret = NULL;free(secret_buf);
secret_buf = NULL;
Да и раньше было:
http://thermal.cnde.iastate.edu/~sdh4/verynice/
> Да и раньше было:
> http://thermal.cnde.iastate.edu/~sdh4/verynice/Спасибо. Действительно очень похоже на сабж. Вот еще нашел в репах debian - renice http://www.cgarbs.de/stuff.en.html
*reniced
Отзывчивость десктопа в Linux отличная без всяких патчей. Во всяком случае по сравнению с Windows версий 95-XP.
> Параметры работы ulatencyd задаются через правила, оформленные в виде скриптов на языке Lua, поэтому пользователь легко может изменить поведениеДа, скрипты на Lua для пользователей - пара пустяков... И вообще, зачем на десктопе гуй?
Я знаю что такое язык программирования состоящий исключительно из GUI в котором всё делается мышекликанием. Поверь, если б ты это видел, то проклял бы его автора и весь его род до пятого колена, а то и дальше. Lua тут на своём месте, простой пользователь настраивать эти скрипты под себя всё равно не полезет, а продвинутый — разберется.
HiAsm?
> Я знаю что такое язык программирования состоящий исключительно из GUI в котором
> всё делается мышекликанием. Поверь, если б ты это видел, то проклял
> бы его автора и весь его род до пятого коленадайте пощупать, хочу ощутить на себе
Не уверен, что речь о LabVIEW, но, вроде, достаточно визуальная фиговина.http://www.ntecs.de/old-hp/uu9r/lang/html/labview.en.html -- картинка.
> Не уверен, что речь о LabVIEW, но, вроде, достаточно визуальная фиговина.
> http://www.ntecs.de/old-hp/uu9r/lang/html/labview.en.html -- картинка.спасибо, даже если не оно - "пощупать мышкой" там есть чего
>Да, скрипты на Lua для пользователей - пара пустяков... И вообще, зачем на десктопе гуй?Это прежде всего для дистрописателей и прочих разработчиков. Сходи по ссылке - там уже готовые скрипты для гнума, кде и пр. Нужно только install. ;)
>Параметры работы ulatencyd задаются через правила, оформленные в виде скриптов на языке LuaПитонисты вполне справедливо возмутятся, почему правила задаются не на Python, перлисты - почему не на Perl, рубисты - почему не Ruby и т.д. Поэтому сделать правила на XML и будет шеколадно.
json же!
чтобы возмущались все и одинаково, ага.
сделать одинаково плохо - не выход
Lua, в отличие от жирных Питона и Перла, в скомпилированном виде больше 180К никогда не занимает. При этом довольно мощный (даже ООП поддерживает) и шустрый. Для языка правил - самое то.
Это же продолжение Марлезонского балета известного LKML-срача "200 строк в ядре vs 4 строчки на bash" и тонких метаний по вопросу должно ли ядро проявлять эвристику, или же сессия - явление юзерспейсовое?Если да - удивлен, что никто не комментирует. С нетерпением ждем реакции Линуса.
>С нетерпением ждем реакции Линуса.:D
Посмотрел. Думаю, будет жить.
Странная тенденция. Все становится слишком сложно - демон через сигрупс на основании нетлинк и тд... А ведь разделение ресурсов - одна из немногих основных функций ядра в теории. Почему в линуксе выстраивают вот такие вот конструкции для того, что другие системы могут просто так? Нелюбимый мной макос, вполне нормально себя ведет при высокой фоновой загрузке, например.
Ядро не имеет никакого понятия о сессиях. Оно не знает ничего про гуй с его виртуальными десктопами, и не понимает в активных и свернутых окнах. И уж, тем более, не знает о мультипроцессовых браузерах и какая там вкладка в Chromium'е открыта.Ядро делит ресурсы, и это оно делать умеет. А вот правила как делить ресурсы ему дает юзерспейсовый демон.
Зачем ему все это знать? Просто делить поравну.
> Зачем ему все это знать? Просто делить поравну.Толстовато.
> Толстовато.Пойдет. :)
Ага, "отобрать все и поделить" :) В результате при перекодировании фильма ffmpeg-ом и одновременного серфинья инета музыку уже слушать невозможно...
Почему? Невозможно будет какраз в случае, если ффмпегу будет отдано почти все процессорное время, если же музакльный плеер будет гарантировано получать свои 25%(упрощенно в случае 4х процессов), то все будет ок.
Вот если делить все поровну, то плеер как раз не будет получать свой процент _гарантированно_, т.к. чем больше будет запущено процессов, тем меньше будет получать каждый из них.
Очевидно, что делится среди тех, кому надо. Да, задача не тривиальная, но то для чего пишутся вот такие демоны в линуксе сейчас реализовано методами ядра в других системах. По личному опыту могу назвать МакОС. Так же читал, что QNX весьма неплох в этом. Кто-то говорил, что фрибзд так же не страдает такими проблемами.
Что ж это за плеер такой которому нужно 25%?
"Windows does not have better scheduling at all. The problem with the linux scheduler that he is just to fair when not adjusted. The windows scheduler is just unfair in general, at least up to vista. Fair in general is better, if it can be adjusted to what the user expects :-)"© автор ulatencyd на http://phoronix.com/forums/showthread.php?28630-ULatencyD-En...
Не думаю что сработает. Одно и тоже гуи приложение может как интенсивно графику рисовать, так и декодировать, кэшировать или ещё что-нибудь. Так же скрипты луа в демоне - плохая идея. Лучше бы иметь хорошую документацию, и уже на уровне дистрибутива предоставлять статические типовые установки.
>Одно и тоже гуи приложение может как интенсивно
> графику рисовать, так и декодировать, кэшировать или ещё что-нибудь.Вполне решаемо, например, с помощью wm.
> Так же
> скрипты луа в демоне - плохая идея. Лучше бы иметь хорошую
> документацию, и уже на уровне дистрибутива предоставлять статические типовые установки.Не осилил. Честно.
> сравним c 200-строчным патчемА может тогда хватит 200 строчного патча? А то скрипты на Lua и эвристика для отзывчивости системы - это уже какой-то злостный оверкилл. Может еще пользователя заодно эвристикой следует заменить? :)
Уже давно так постепенно и происходит
Как раз нормально. Иначе получаем забитые гвоздями правила. А так - имеем гибкую механику.
> Как раз нормально. Иначе получаем забитые гвоздями правила. А так - имеем
> гибкую механику.А кому она нужна, эта гибкая механика? Полутора землекопам? Юзеры ни в зуб ногой в этом - им надо чтобы "просто работало". Эстетов которые будут ацца с луа-скриптами чтобы систему не клинило и оценят все навороты - на всю планету с десяток наверное не найдется.
> А может тогда хватит 200 строчного патча? А то скрипты на Lua
> и эвристика для отзывчивости системы - это уже какой-то злостный оверкилл.
> Может еще пользователя заодно эвристикой следует заменить? :)Отзывчивость относится к удобству использования (юзабилити) и поэтому однозначно относится к пользовательскому уровню; ядро об этом ничего не должно знать.
PS. Меня беспокоит судьба mpd (music player daemon): музыку он в фоне-то проигрывает, и не хотелось бы при высокой нагрузке, чтобы музыка "икала"...
> Отзывчивость относится к удобству использования (юзабилити)Отзывчивость относится к качеству работы системы. Хорошая операционка не должна позволять одним вызвать существенную деградацию качества работы других.
> и поэтому однозначно относится к пользовательскому уровню;
> ядро об этом ничего не должно знать.Сродни заявлению "ядро не должно хорошо работать без костылей". Не, извините, если одинаковый результат достигается патчем на 200 строк и мегатурбовелосипедом требующим аж программить скрипты на луа - шло б оно такое, а? 200 строк - меньше говна в системе, а типичный юзер все-равно не заметит результата. А осчастливливать полтора гуры - неблагодарное дело. Они покряхтят но и без супердемонов с луа справятся имхо :)
> PS. Меня беспокоит судьба mpd (music player daemon): музыку он в фоне-то
> проигрывает, и не хотелось бы при высокой нагрузке, чтобы музыка "икала"...А что, накрайняк ему приоритет поднять - это такая нереальная инженерная задача? oO
>> Отзывчивость относится к удобству использования (юзабилити)
> Отзывчивость относится к качеству работы системы. Хорошая операционка не должна позволять
> одним вызвать существенную деградацию качества работы других.Вы смешиваете, имхо, понятия ОС и ядро ОС:
- ядро должно иметь возможность перераспределением своих ресурсов (процессорного времени)
- ядро не должно динамически управлять этой возможностью, т.е. управлять само собой, отвечая потребностям юзера
- ОС (в широком смысле), конечно, должно управлять ресурсами.Т.е. пользователь логинится, запускает браузер, и в терминале make -j50 для сборки Qt. Для ядра это равнозначные процессы, и раз пользователь не указал их различные приоритеты, то и будет равномерно распределять время между 51 процессом -> будет тормозить. И ядро НЕ ДОЛЖНО знать, что какой-то процесс, браузер (/usr/bin/firefox? /bin/browser?), оказывается, вопреки пожеланию пользователя, высокоприоритетным в отношении ресурсов...
А предлагаемый эвристический демон, как раз-таки должен, зная "обычные" предпочтения пользователя (вроде высокоприоритетности /usr/bin/firefox) разруливать ресурсами.
Ядро как это двигатель авто, который конечно должен иметь возможность делать "максимальные обороты", но он не должен делать этого "по умолчанию".
>> и поэтому однозначно относится к пользовательскому уровню;
>> ядро об этом ничего не должно знать.
> Сродни заявлению "ядро не должно хорошо работать без костылей". Не, извините, если
> одинаковый результат достигается патчем на 200 строк и мегатурбовелосипедом требующим
> аж программить скрипты на луа - шло б оно такое, а?
> 200 строк - меньше говна в системе, а типичный юзер все-равно
> не заметит результата. А осчастливливать полтора гуры - неблагодарное дело. Они
> покряхтят но и без супердемонов с луа справятся имхо :)1. Не смешивайте понятия: 200-строчный патч тоже нужно было кому-то программить (системному программисту), как и демона с луа-скриптами (пользовательскому программисту). Конечному пользователю (убунтойду, да и гентушнику) не нужно ни то, ни другое делать ;-). Кроме того тюнингующий демон ("эвристика") может справиться с задачей, когда, скажем 2 чисто пользовательские программы тормозят: например, eclipse компилирующий толстый проект и браузер. Очевидно, те 4 минуты компиляции, пользователь захочет почитать opennet и посмотреть ютюб и он не должен торомозить даже на относительно слабом железе.
>> PS. Меня беспокоит судьба mpd (music player daemon): музыку он в фоне-то
>> проигрывает, и не хотелось бы при высокой нагрузке, чтобы музыка "икала"...
> А что, накрайняк ему приоритет поднять - это такая нереальная инженерная задача?
> oO2. Как я понял, mpd не вяжется в концепцию патчика (он мониторит терминалы, а mpd запускается как системный процесс), но прекрасно вяжется с концепцией тюнингующего демона. Поэтому патч + запуск mpd с повышенным приоритетом - и есть костыль.
"евристика" lua-конфигов...
local MediaPlayer = {
"vlc",
"xine",
"mplayer.*",
"dragon",
"totem",
"kplayer",
-- audio players
"amarok",
"parole",
"listen",
"rhythmbox",
"exaile",
}...
Ты бы вообще оставил здесь только одну строчку из того скрипта. Тогда сомнений в плохой эвристике у нас не осталось бы.
Это было адресовано тем, кого так страшат lua скрипты. На счет наличия эвристических алгоритмов не смотрел, может оно и есть. Но пока больше похоже на простые списки приложений - какое в какую cgroups пихать. Потенциально, да, можно сделать много красивого и не очень.
Фаг, тебе не повезло, значит, mpd будет "икать". :D
>>** INFO: mount cgroups: /bin/mount -t cgroup -o blkio none /dev/cgroup/io/
>>mount: специальное устройство none не существуетЭто нормально? ;-)
Я местами тащусь с линукса, честно :) потом ведь еще изобретут кучу вареза для автоматической генерации конфигов.Но интересно, так как мой десктоп не линукс, такие чудеса на виражах мне неизвестны, но кажется user294 писал что cgroups решают.. так выходит чо, не решают? Выходит еще демон нужен с конфигурятором?..
Иногда так почитаешь user294 да поставишь себе в очередной раз на ноут линукса, поиграешься, да потом наткнешься на какойнить прикол типа кривизны со звуком, так и забьешь на это дело. Щас вот бубунта стоит 10.10 редакция для нетбуков, вроде ничо, хотя в первый раз после загрузки наглухо повисла, пришлось повером ребутать..
Казалось бы, а при чем тут юзер? ;) Ваше дело - ждать следующей версии бубунту, в которой оно _уже_ будет прикручено или выбирать что-то другое.
> Казалось бы, а при чем тут юзер? ;) Ваше дело - ждать
> следующей версии бубунту, в которой оно _уже_ будет прикручено или выбирать
> что-то другое.Кто-то постоянно с разных ников ему гадости пишет вот уже месяца два. Но хоть убунту тоже не любит, что уже хорошо.
я вон на BFS сижу, и ничо так...
генту бывает мержишь с LA=11 или иногда даже 12 а амарок спокойно себе играет и сёрфишь тоже легко по инету.
> я вон на BFS сижу, и ничо так...
> генту бывает мержишь с LA=11 или иногда даже 12 а амарок спокойно
> себе играет и сёрфишь тоже легко по инету.Суся. 2006 год. Запускаю амарок одновременно с компиляцией программы, игрой в Wine, и фаерфоксом 2 версии. Амарок стартует. Ничего не тормозит, кроме игры в Wine совсем чуть-чуть (нативная бы не тормозила). Через 40 секунд амарок стартовал, и уже запущенный амарок тоже не тормозил. От Windows такого не дождёшься. Медиаплеер стартует 3 секунды, а за это время вся система едва живая. После появления двухъядерного процессора эта проблема забыта, как мне кажется, навсегда.
P.S. Сёрфить по инету - с этим и второй пентиум с MMX справится. Если не в 20 окон и emerge не запущен.
/usr/src/poelzi-ulatencyd-85a2307/src/ulatencyd.c: В функции ‘avoid_oom_killer’:
/usr/src/poelzi-ulatencyd-85a2307/src/ulatencyd.c:119: ошибка: ‘O_NOFOLLOW’ не описан (первое использование в этой функции)
#define O_NOFOLLOW 00400000
Интересно, как оно будет работать с systemd, использующим cgroups для своих целей?
ulatencyd (28670): /proc/28670/oom_adj is deprecated, please use /proc/28670/oom_score_adj instead.Гы :)
