Сравнение планировщиков задач в линукс

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

> Это еще чего за бред? Хочешь побороться за орден "труженик 4.2"?

так, быстро нашёл библиотеку тредов в Xorg'е:

# ldd `which Xorg`
        linux-gate.so.1 =>  (0x00110000)
        libdl.so.2 => /lib/libdl.so.2 (0x0030a000)
        libXfont.so.1 => /usr/lib/libXfont.so.1 (0x00340000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0x0044c000)
        libfontenc.so.1 => /usr/lib/libfontenc.so.1 (0x00311000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00444000)
        libselinux.so.1 => /lib/libselinux.so.1 (0x0091a000)
        libm.so.6 => /lib/libm.so.6 (0x002df000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x005c8000)
        libc.so.6 => /lib/libc.so.6 (0x00189000)
        /lib/ld-linux.so.2 (0x0016a000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00463000)
        libz.so.1 => /lib/libz.so.1 (0x0032b000)
        libsepol.so.1 => /lib/libsepol.so.1 (0x0085a000)

нету? может иксы без неё обходятся?

> ls /proc/`ps -A|grep Xorg|awk '{print $1}'`/task|wc -l
1

видимо мультитредный х-сервер существует только в твоём воспалённом мозгу, в следующий раз проспись прежде чем писать на ЛОРе

> Как бы то ни было, признаю свою вину в том, что в пылу беседы спровоцировал значительное отклонение от темы беседы.

Ничего, все это соответствует традициям ЛОРа - не ходить по ссылкам и устраивать в каждом топике, например, про планировщики и винду и солярис и глобальное потепление климата на планете и пэхопэ с перлом и жабобыдлокодерами и софт на АЭС, и космические корабли бороздящие просторы Оперного театра...

> незамутненная даже элементарными нормами вежливости и уважительности по отношению к собеседнику

Переход на ты или прямое указание на логические несостыковки не является оскорблением. Некоторые наоборот считают почти что оскорблением или включением собеседником дистанцирующего защитного механизма когда выкают при личной беседе или на форуме.

> устраивать в каждом топике, например, про планировщики

Читать как "устраивать в каждом топике, например, про планировщики, оффтопики"

>Изначально было ясно, что единое комьюнити и уменьшение спектра программ - это великий плюс и общая задача, всяко лучше решаемая в отличие от нынешнего зоопарка и велисипедостроения, что лишь откалывает разработчиков и приводит к раскладу "лучше быть начальником канализации с Усть-Пердинске, чем простым инженером, скажем, в Париже". Gharik (*) (08.08.2007 16:35:16)

Это про altlinux?

>вот только незадача - под обычным нерутовым юзером нельзя менять приоритет в минус.

Дружок, а может тебе еще rt дать? То, что все процессы по умолчанию пускаются с максимально доступным для пользователя приоритетом (nice 0) - не вина планировщика. Пускай все с +20, а "вендовое окно" с 0. Усек?

>так, быстро нашёл библиотеку тредов в Xorg'е:

Все проще дружок. Я понял, что ты имел в виду, правда лишь после того как запостил свой ответ.

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

Понимаешь ли, отрисовка кнопучек - это лишь мизерная, я бы сказал, незначительная, часть того, от чего зависит интерактивность приложения. Дальше продолжать?

По существу. Ты правда думаешь, что для отрисовки окошек требуются _такие_ мегаресурсы, что это прямо-таки жизненно необходимо распараллеливать? Смешно.

Если тебя это так сильно беспокоит, то можешь сделать renice -20 для иксов. :D

> Если тебя это так сильно беспокоит, то можешь сделать renice -20 для иксов. :D

Проблема в другом - в том, что приоритеты клиентов разные, но, когда сервер обрабатывает запросы от них, он делает это на одном и том же приоритете. В NT есть ImpersonateClient, который теоретически предназначен для таких ситуаций, но в Unix ничего подобного нет.

> Очень странно. Не могли бы вы подробнее описать эти "подвисания"? Может это конфликт какой.

> Подробней? Симптомы:

> (а) приложения: Opera, KMail, OOo 2.2.0 ИнфраРесурс. Раньше в качестве mail-клиента использовался Thunderbird, тоже "подвисал". Еще раньше в качестве Web-браузера использовался Firefox, тоже "подвисал". Что странно, в основных рабочих приложениях (Konsole и vim, запущенный в Konsole) таких "подвисаний" не бывает;

Гхмм, видимо, я не так активно работаю с этими приложениями, хотя Firfox использую регулярно. Сам FireFox подвисает только когда загружает очень большую страницу и парсит её.

> За время набора этого текста случилось два таких "подвисания".

Ext3FS? Это привет от его журналирования. По крайней мере, часто так. Может ещё и не включено noatime в опциях в fstab? В LKML было длинное и долгое обсуждение темы.

> Ext3FS? Это привет от его журналирования. По крайней мере, часто так. Может ещё и не включено noatime в опциях в fstab? В LKML было длинное и долгое обсуждение темы.

Ребят, вы о чем-то из параллельной вселенной разговариваете... Какие подвисания? Какое журналирование? Да я спокойно на системен с LA=500 работал. Мож у вас с железом что-то не то? Таких "детских" болезней, как "подвисания", да еще на заметные времена у Linux уже нет лет 5 как.

>> За время набора этого текста случилось два таких "подвисания".

> Ext3FS? Это привет от его журналирования.

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

>Проблема в другом - в том, что приоритеты клиентов разные, но, когда сервер обрабатывает запросы от них, он делает это на одном и том же приоритете.

Ну дык и поставить ему приоритет максимальный. Все равно он много не хавает. Да и предположение о том, что "тормоза" у некоторых товарищей из-за проблем с планировщиком, по меньшей мере наивны. Вы правда думаете, что отрисовка окошка является какой-то ресурсоемкой задачей? Если и есть какие-то проблемы в этой сфере, то их стоит искать либо в иксах, либо не в "окошках" (в том, чем там еще занимается ваши программки/гуевые библиотечки с "тормозящими" кнопочками. ).

>В NT есть ImpersonateClient, который теоретически предназначен для таких ситуаций, но в Unix ничего подобного нет.

Ну что вы все со своей вендой то лезете. :Е Будете приводить такие сравнения после того как в лялих (ядро) гуйню засунут.

>>Проблема в другом - в том, что приоритеты клиентов разные, но, когда сервер обрабатывает запросы от них, он делает это на одном и том же приоритете.

>Ну дык и поставить ему приоритет максимальный. Все равно он много не хавает.

Ну дык проблема не только к X-серверу относится.

>>В NT есть ImpersonateClient, который теоретически предназначен для таких ситуаций, но в Unix ничего подобного нет.

>Ну что вы все со своей вендой то лезете.

Ути-пути, какие мы идеологически чистые. Венда не наша, а противника нужно знать.

> Будете приводить такие сравнения после того как в лялих (ядро) гуйню засунут.

В огороде бузина, в Киеве дядька.

$ cat /etc/fstab | grep hdc
/dev/hdc1  /          ext3  acl,user_xattr         1 1
/dev/hdc2  /home      ext3  acl,user_xattr         1 2
/dev/hdc3  /localftp  ext3  acl,user_xattr,noexec  1 2
/dev/hdc4  swap       swap  defaults               0 0

Да, ext3fs, но опции noatime нет.

P.S. Почему /dev/hdc? Не имею права что-то делать с /dev/hda.

>Ну дык проблема не только к X-серверу относится.

Я бы сказал она к нему не относится. Но все же было бы интересно выслушать твое мнение, к чему она относится?

> Венда не наша, а противника нужно знать.

Товарищ, про приоритет окошка "как в венде" выше уже не однократно ответили. Или ты не читатель?

>P.S. Почему /dev/hdc?

Кыш отседова! :)

Превратили, понимаешь, тему в рассадник троллей. :D

>>Ну дык проблема не только к X-серверу относится.

>Я бы сказал она к нему не относится.

Люди вроде Алана Кокса и Кита Пакарда с тобой не согласились бы.

> Но все же было бы интересно выслушать твое мнение, к чему она относится?

К любому серверу. Разве это не очевидно?

>> Венда не наша, а противника нужно знать.

>Товарищ, про приоритет окошка "как в венде" выше уже не однократно ответили. Или ты не читатель?

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

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

Это уже совсем другой вопрос и отношения к задержкам и "тормозам" не имеет.

Правда, для меня не очивидно:
- при чем тут планировщик и зачем это тащить в ядро
- как это можно эффективно реализовать в планировщике
- на сколько это необходимо
- почему серверу не разрешают использовать nice

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

>Это уже совсем другой вопрос и отношения к задержкам и "тормозам" не имеет.

Почитай о том, что такое "priority inversion" и не говори глупостей

> Правда, для меня не очивидно:

> - при чем тут планировщик и зачем это тащить в ядро

> - как это можно эффективно реализовать в планировщике

См. выше

> - на сколько это необходимо

Смотря для кого и чего

> - почему серверу не разрешают использовать nice

Разрешают, но это не решает проблемы

Пока я читаю про priority inversion :) ответь на вопрос, почему

>это не решает проблемы

? Казалось бы, дергай себе nice на здоровье..

>>это не решает проблемы

>? Казалось бы, дергай себе nice на здоровье..

А, ты предлагаешь на уровне приложения организовать управление приоритетами? Это можно, конечно, и даже, наверное, будет работать. Но 1) это придется реализовывать в каждом приложении 2) то, что об этом не знает ОС, не дает ей эффективно планировать глобальные ресурсы (IO, память). То есть - кастыль.

Немного почитал. К сожалению, пока времени немного.. =(

Вещь интересная, и, вероятно, нужная. Особо критичная для rt систем.

Но, непонятно, что там с реализацией. (Видимо, оно не красиво, либо не эффективно получается).

Также я убежден, что проблема "плачущих" в данной теме кроется в чем-то другом.

+ проблема с иксами в таком случае легко и непринужденно решается задиранием приоритета.

> Также я убежден, что проблема "плачущих" в данной теме кроется в чем-то другом.

...но фактов для обоснования - нет :)

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

если оно динамическое - да. Но вот незадача - X-протокол не предусматривает передачи приоритета клиента, так что задача практически не решается. И постоянно дергать приоритет - это кастыль.

>но фактов для обоснования - нет :)

Знаешь, мне вообще трудно чем-либо кроме /dev/hands обосновать пятисекундные замирания. :D

На счет иксов, не совсем понял.. Зачем им передавать приоритет, если он итак максималный. В таком случае х-сервер точно крайним не будет.

В любом случае, было бы интересно услышать отчеты страждущих при использовании CFS. Тем более, что там какой-то inheritance имеется. )

>http://lwn.net/Articles/232243/

> - bugfix: handle Priority Inheritance properly (Thomas Gleixner)

> счет иксов, не совсем понял.. Зачем им передавать приоритет, если он итак максималный. В таком случае х-сервер точно крайним не будет.

Потому что X-серер должен брать на обслуживание заявки от клиентов в порядке приоритета - иначе инверсия.

Хмм.. что-то грустно все закручивается.. :)

Есть информация, что там у нас с реализацией и на сколько оно _реально_ сказывается, скажем, на типовой рабочей станции?

>Потому что X-серер должен брать на обслуживание заявки от клиентов в порядке приоритета - иначе инверсия.

Да какая там разница, он их все равно выстреливает только в путь. :0 А блокироваться там вроде как и нечему. =\

> Есть информация, что там у нас с реализацией

Реализацией чего?

> Да какая там разница, он их все равно выстреливает только в путь. :0

Разница в том, что низкоприоритетный запрос ждет высокоприоритетного. Долго ли ждет - другой вопрос. Лаги в звуке ощущаются на миллисекундах.

> А блокироваться там вроде как и нечему. =\

Да хотя бы на swapped out странице.

>Реализацией чего?

Наследования приоритетов. В cfs какие-то похожие слова присутствуют.. :D только вот оно это или нет, я что-то до конца не понял.. Если это не то, то есть ли какие-либо телодвижения в эту сторону? Гугль коварно молчит. =(

>Лаги в звуке ощущаются на миллисекундах.

Что-то не вижу корреляции звука и x-сервера. :]

>Да хотя бы на swapped out странице.

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

>>Реализацией чего?

>Наследования приоритетов.

Работы ведутся в рамках ветки -rt. ИМХО, они уже закончены, но Линус по каким-то причинам не взял (пока) их в ядро. Раньше вообще отношение к RT в mainline было довольно отрицательное, но сейчас ситуация сильно изменилась благодаря Инго и К. Правда, вопрос полного слияния -rt и mainline пока открыт. На сегодня уже реализованы (и, насколько я помню, приняты в ядро) futex'ы с наследованием приоритетов;

Правда, следует помнить, что всё это добро действует только в рамках процесса и в ядре - внутри клиент-серверных приложений всё по-старому (инверсия приоритетов возможна).

>Что-то не вижу корреляции звука и x-сервера. :]

Это для примера.

Понэл, спасибо. )

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

Я ленив, я очень ленив, ленивее меня только муха, покрытая пылью. Но даже при моей лени я умею читать. Вот примерное начало (она началась раньше, но читать интересно отсюда) ветки про журналирование, fsync, ext3: http://www.ussg.iu.edu/hypermail/linux/kernel/0708.0/1435.html

Я не понимаю, о чем говорят столь именитые личности. Они утверждают, что на вызове fsync(), для определенного файла происходит сброс _всего_ дискового кэша, что приводит к моментным фризам.

Я написал скрипт while(true); do sync; sleep 3; done

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

> Я не понимаю, о чем говорят столь именитые личности.

Похоже на то.

Я попробую объяснить на пальцах, и в частности на редакторе Vim. При редактировании файла, Vim периодически делает fsync, который заставляет слить полностью накопленный, но не закомиченный журнал, в журнале часто оказываются такие относительно бесполезные (в реальном времени) данные, как atime (access time, время последнего доступа/чтения файла), в этот момент Vim может "подвисать", хотя редактироваться может файл размером в несколько байт. Получается, что проблем две: грубо сделанный журнал ext3 и довольно большое количество не очень полезных данных в этом журнале. Поэтому, fsync в каком-нибудь приложении может вызвать заметную пиковую загрузку диска, что и приведёт к "подвисанию" какого-либо другого приложения, которое в этот момент, например, просто захотело почитать иконки при открытии меню, например. С журналом в ext3 никто бороться не собирается, решение проблемы оставили на ext4, а вот проблема atime была в той ветке, что я привёл, рассмотрена более подробно, говорят, что на апдейтах atime теряется до 20-30 %% дискового быстродействия.

Спасибо за разъяснения, я это успел прочитать в рассылке.

Мне непонятно, почему:

1. Это заметили (по крайней мере стали серьезно обсуждать) в 2007 году, а не 5 годами раньше, когда ext3 появилась.

2. Почему я, человек с 5 летним опытом использования Linux, в тяжелых дисково-лимитированных расчетах, на разном железе, ничего подобного не наблюдал? Правда, vim я использую очень редко.

3. Почему опыты с sync ничего не показали? Или вызов fsync() в программе и sync из командной строки оказывают разное влияние на дисковый кэш (и журнал fs)?

> 1. Это заметили (по крайней мере стали серьезно обсуждать) в 2007 году, а не 5 годами раньше, когда ext3 появилась.

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

> 2. Почему я, человек с 5 летним опытом использования Linux, в тяжелых дисково-лимитированных расчетах, на разном железе, ничего подобного не наблюдал? Правда, vim я использую очень редко.

Нужны достаточно специфичные условия, видимо, чтобы проблема проявилась отчётливо. Например, одновременный апдейт большого количества метаданных, разбросанных по диску, чтобы нагрузка была seeky. "Тяжёлые дисково-лимитированные расчёты" вряд ли такую нагрузку создают, а если и создают, то может мимо журнала, поскольку в журнале только метаданные (data=ordered, дефолт в ext3).

> Почему опыты с sync ничего не показали?

Наверное потому, что журнал пустой. Запусти, например, tar на архивацию большого дерева, пусть даже в /dev/null, и sync должен будет его притормаживать, несмотря на то, что это не имеет большого смысла.

> Наверное потому, что журнал пустой. Запусти, например, tar на архивацию большого дерева, пусть даже в /dev/null, и sync должен будет его притормаживать, несмотря на то, что это не имеет большого смысла.

Запустил

$ tar -cv /usr >&/dev/null&

$ while(true); do sync; usleep 200000; done

затем еще раз архивирование, но уже

$ while(true); do sync; sleep 4; done

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

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

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

Правильно, ты пишешь ответ в браузере, которому винт для работы в этот момент не нужен. А вот если б ты полез в букмарки и там надо было отобразить иконки ссылок, и эти иконки не в памяти браузера, то браузер мог бы притормозить.

> Правильно, ты пишешь ответ в браузере, которому винт для работы в этот момент не нужен. А вот если б ты полез в букмарки и там надо было отобразить иконки ссылок, и эти иконки не в памяти браузера, то браузер мог бы притормозить.

Согласен, терминал, скажем, стал заметно медленнее открываться. Но опять-таки, разве это не штатное поведение? Обслуживать I/O от всех клиентов надо, не только от моих окошек.

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

Ладно, спасибо за терпение. Постараюсь следить за этой темой. Если будет что-то еще интересное, будьте любезны, опишите! :)

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

понятно, руки работают быстрее головы, админом тебе работать противопоказано ;)

> Понимаешь ли, отрисовка кнопучек - это лишь мизерная, я бы сказал, незначительная, часть того, от чего зависит интерактивность приложения. Дальше продолжать?

> По существу. Ты правда думаешь, что для отрисовки окошек требуются _такие_ мегаресурсы, что это прямо-таки жизненно необходимо распараллеливать? Смешно.

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

> x11perf -all

попереключай/потаскай/пооткрывай окна и удивись, как твой мегакомп жутко тормозит, это чистой воды тест, но никто не гарантирует, что не встретится приложение создающее ситуацию сходную с тестовой

ps зарегься, разговаривать с тобой под анонимом больше не буду