я знаю как минимум двух людей, которые тоже над этим работали :) Один из них Alex Tomas, он же bzzz, а второй я. Но ни тот не другой патчи недыли достаточно стабильными...

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

а зачем это?

Теперь для добавления нового планировщика не нужно изменять другие части ядра - он может быть сделан модулем ядра. Как минимм польза - более прозрачное API. В то же время облегяает экспериментирование с планировщиками для оптимизации системы (кому это нужно). Это насколько я понимаю

С первым не согласен. По сути они и так были модулями, только вкомпиленными, то есть прямых вызовов небыло. Так что АПИ мне кажется остался на прежнем уровне.

А вот второй да, в какой то степени :)

Гм. Они и так были в системе. Другой момент, что переключиться можно было только при перезагрузке. Интересно, насколько стабильный патч.

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

Да ладно, зато фича звучная =) Можно будет потом тыкать и говорить: "а вот в винде/бсде/макоси такого нет!"

Не буду спорить - просто предположил.

Jens Axboe: With the io schedulers fully modular, it is possible to add a new io scheduler type without touching the core kernel at all. elv_register() and elv_unregister() register a new io scheduler with the elevator core.

Наврятли, Линус это примет... Ведь это путь|шаг к микроядру...

> Наврятли, Линус это примет... Ведь это путь|шаг к микроядру...

Согласен! На днях провел маленькое исследование и выяснил, что код собственно ядра всего около 1%. (Больше половины - драйверы, значительная часть исходников поддержка файловых систем и других архитектур.) Т.о. не должно составить особого труда переработать его под микроядро.

Не путайте модульное моноядро с микроядром. В микроядерной ОС драйверы, и, возможно, распеределители памяти и планировщики процессов работают в userspace. Разница очень велика.

Поддержка модулей моноядром - ни разу не шаг по направлению к микроядру.

Да? А почему тогда Линус принял поддержку модулей ядра? Или по вашему моноядро - это как у OpenBSD?

Почему же? Например, у меня рабочая станция. И я занимаюсь базами данных и попутно собираю что-то.

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

А можете подсказать какой шедулер лучше для сервера с samba(1C) использовать с целью повышения производительности?

>А можете подсказать какой шедулер лучше для сервера с samba(1C) использовать с целью повышения производительности?

Не смешите мои тапочки, Вы что собираетесь с 0,1% загрузки проца до 0,09% оптимизировать? ;)

Никаким образом не собираясь смешить ваши штампики я просто интересовался будет ли самбе от выбора "правильного" шедулера лучше? А загрузка самбовских процессов и 20% достигала.

Между прочим в OpenBSD есть LKM, другое дело, насколько хорошие ;-)

В NetBSD есть похожая штучка, bufq называется.

про планировщики в Mac OS (читай: Mach)

> Можно будет потом тыкать и говорить: "а вот в винде/бсде/макоси такого нет!"

В Mac OS X есть ТАКОЕ. Потому, что это в Mach есть. Так что это они будут тыкать, что теперь (не прошло и 30 лет) и в Linux можно менять планировщик "на ходу" :)

Бугага, dselect, сколько не читаю твои сообщения, всегда поражаюсь твоей тупости :) Ну ты же ламер, ну что ты кричишь?

Про Mach.

То, что ты говоришь, нызывается scheduling policy - это ну просто даже рядом не стояло с понятием scheduler, т.к. mach - микроядро, то все IO процессы живут в userspace потоках, и к ним применяется обычный шедулер, который и понятия не имеет о том, что данный поток что-то будет писать на диск и т.п.

Я тоже не знаю :-) Ориентирвоался по этому http://kerneltrap.org/node/view/3239

Во, почитай на досуге...

http://cs.uml.edu/~cgould/

MacOS X 30 лет? Где она была в 74...

немного не по теме, но просветите ламера по следующему вопросу. запускаем мы машину, загрузилось ядро, система стартанула, всё ок. в ядре есть ряд пареметров (н.п. объём различного рода буферов) с которыми оно по умолчанию работает. я беру и на ходу через sysctl меняю размер некоторого буффера с большего на меньший. если этот буфер был заполнен полностью, что произойдёт с данными, которые в нём хранились и теперь уже в новый размер буфера помещаться по идее не должны?

> То, что ты говоришь, нызывается scheduling policy - это ну просто даже рядом не стояло с понятием scheduler

Стояло.

> т.к. mach - микроядро, то все IO процессы живут в userspace потоках, и к ним применяется обычный шедулер,

Какой из них называется "обычный"?

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

Очень даже имеет. Точнее, для [потоков] сервера ФС назначается другой планировщик, нежели для "простых" потоков.

обычный, это тот же, что и для всех остальных процессов в системе.

нет, мой юный друк, планировщик в mach всего один, а для разных потоков применяется разные scheduling policy, которые сводятся в конечном счете всего лишь к хитрому манипулированию thread priority. Я просто уверен, что ты не знаешь, как устроены IO планировщики в linux, поэтому и пытаешься сравнивать то и это. Планировщик Mach похож на O(1) планировщик, но только с расширенным набором RT приоритетов. В Mach нет впециального IO планировщика. Просто нет,

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

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

Зависит от реализации - ядро ДОЛЖНО в таких случаях отслеживать использованный объем буферов и не уменьшать их сверх этого объема - это в теории.

Да, забыл сказать, ты можешь менять на лету scheduling policy, на насколько я слышал, в линуксе тоже можно менять приоритет приложения.

Только в mach это можно делать несколько более обширно, не понятно только, зачем...

спутал с L4

> планировщик в mach всего один

Таки да, один. То я спутал с L4 (см. http://l4hq.org/docs/manuals/l4-x2-20040823.pdf, глава "Scheduling")

> а для разных потоков применяется разные scheduling policy, которые сводятся в конечном счете всего лишь к хитрому манипулированию thread priority.

Ставим потоку приоритет в соответствии с тем, сколько квантов времени он израсходовал(как долго находится в готовом состоянии, но не запускался) -- получаем "обычный" [time-sharing] планировщик.

Ставим потоку приоритет в соответствии с тем, сколько он записал (сколько ему надо записать, если он блокирован) -- получаем I/O планировщик ("I/O sharing"?)

(Mach так не может.)

> Ставим потоку приоритет в соответствии с тем, сколько квантов времени он израсходовал(как долго находится в готовом состоянии, но не запускался) -- получаем "обычный" [time-sharing] планировщик.

>Ставим потоку приоритет в соответствии с тем, сколько он записал (сколько ему надо записать, если он блокирован) -- получаем I/O планировщик ("I/O sharing"?)

>(Mach так не может.)

Тут тоже все не так просто, в linux IO планировщики предугадывают дальнейшие действия исходя из накопленной статистики, так легко отобразить эту информацию в приоритет нельзя.

К тому же как себя вести в ситуации, когда планировщик выставил процессу, который пишет/читает(вызывает функцию write()/read()) приоритет настолько высокий, что процесс, котороый непосредственно обрабатывает запросы(назовем его процессом файловой системы) не может начать работать или работает с очень большими задлержками.

Кто-то назовет подобное поведение "real-time", что является в корне ошибочным и, как показывает практика, и менее(а зачастую чразвычайно) производительным.

Вот что можно сказать про микроядерный подход, экстраполирую фразу Алана Кокса: "Потоки для тех, кто не умеет программировать конечные автоматы". Грамотно построенная монолитная система _в_принципе_ всегда более производительна, чем микроядерная.

> Тут тоже все не так просто, в linux IO планировщики предугадывают дальнейшие действия исходя из накопленной статистики,

Можно, только зависимость приоритета от того-сколько-надо-записать и еще-кучи-параметров не будет функцией (если кто помнит термодинамику: приоритет -- это не функция состояния, это функция процесса); в первом приближении можно взять какую-нибудь простенькую петлю гистерезиса и играться ее параметрами.

> так легко отобразить эту информацию в приоритет нельзя.

Дык я и не сказал что это легко.

> К тому же как себя вести в ситуации, когда планировщик выставил процессу, который пишет/читает(вызывает функцию write()/read ()) приоритет настолько высокий, что процесс, котороый непосредственно обрабатывает запросы(назовем его процессом файловой системы) не может начать работать или работает с очень большими задлержками.

Ставить приоритет такому процессу как сумму (с коеффициентами <= 1) time-sharing priority и I/O priority; т.е. назначить ему более другой планировщик.

А вообще-то, deadlock всегда можно устроить... :(

> Кто-то назовет подобное поведение "real-time", что является в корне ошибочным

Планировщик, который может завести в такую даль, ни разу ни RT (гарантии предоставления ресурсов не выполнены).

> и, как показывает практика, и менее(а зачастую чразвычайно) производительным.

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

> экстраполирую фразу Алана Кокса: "Потоки для тех, кто не умеет программировать конечные автоматы".

gcc для тех, кто не умеет программировать на ассемблере.

> Грамотно построенная монолитная система

Про то, что ее не всегда возможно постороить (или получается уродец вроде Mosix), и что ее гораздо труднее спроектировать, Вы скромно промолчали...

> _в_принципе_ всегда более производительна, чем микроядерная.

В принцип! (C) старый советский анекдот. :)

>> Тут тоже все не так просто, в linux IO планировщики предугадывают дальнейшие действия исходя из накопленной статистики,

>Можно, только зависимость приоритета от того-сколько-надо-записать и еще-кучи-параметров не будет функцией (если кто помнит термодинамику: приоритет -- это не функция состояния, это функция процесса); в первом приближении можно взять какую-нибудь простенькую петлю гистерезиса и играться ее параметрами.

Нет, т.к. при этом нужно учитывать не только приоритет, и в этом основная проблема. Нельзя, просто невозможно, имея только один параметр, управлять подобной IO системой. Хорошо, управлять можно, но получится deadline или noop планировщик.

>> так легко отобразить эту информацию в приоритет нельзя.

> Дык я и не сказал что это легко.

Нет, вообще нельзя, а так легко, как написно, тем более.

>> К тому же как себя вести в ситуации, когда планировщик выставил процессу, который пишет/читает(вызывает функцию write()/read ()) приоритет настолько высокий, что процесс, котороый непосредственно обрабатывает запросы(назовем его процессом файловой системы) не может начать работать или работает с очень большими задлержками.

>Ставить приоритет такому процессу как сумму (с коеффициентами <= 1) time-sharing priority и I/O priority; т.е. назначить ему более другой планировщик.

А вообще-то, deadlock всегда можно устроить... :(

Дело даже не в deadlock - когда есть небиективное отображение параметров системы, всегда будут потери и потенциальные локи. В linux IO планировщики обладают широкими возможностями по управлению потоком данных, а не только приоритетом.

Впрочем, я не собираюсь убеждать кого-то.

>> Кто-то назовет подобное поведение "real-time", что является в корне ошибочным

> Планировщик, который может завести в такую даль, ни разу ни RT (гарантии предоставления ресурсов не выполнены).

>> и, как показывает практика, и менее(а зачастую чразвычайно) производительным.

> Если Вы имеете в виду среднюю температуру по палате (производительность, усредненная по большому промежутку времени и большому числу процессов), то это так. Но она -- не всегда адекватный показатель.

Нет, всего лишь скорость работы одних и тех же IO задач в RT системах и нет. Хотя бывают и исключения, на linux kernel summit в этом году рассказывали, как перенеся драйвер ATA в userspace, автор получил более высокие скорости работы...

>> экстраполирую фразу Алана Кокса: "Потоки для тех, кто не умеет программировать конечные автоматы".

> gcc для тех, кто не умеет программировать на ассемблере.

Не нужно ерничать, если ты считаешь, что gcc vs asm тоже самое, что потоки и конечные автоматы вообще и микроядерный планировщик против IO планировщика в linux kernel, то продолжать бессмысленно.

>> Грамотно построенная монолитная система

> Про то, что ее не всегда возможно постороить (или получается уродец вроде Mosix), и что ее гораздо труднее спроектировать, Вы скромно промолчали...

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

>> _в_принципе_ всегда более производительна, чем микроядерная.

> В принцип! (C) старый советский анекдот. :)

Есть подозрение, что dselect так и не понял, почему микроядерный планировщик с возможностью управления только приоритетом потока(пусть даже сколь угодно нетривиальными алгоритмами) не может и никогда не сможет сравниться и сравниваться с полноценными IO планировашиками, имеющими возможность оценивать поток данных "изнутри".

Дискуссия завершена.

stop microkernel FUD!

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

А кто сказал, что учитывается только приоритет?

> Нельзя, просто невозможно, имея только один параметр, управлять подобной IO системой.

А он и не один. Ядро [L4] не накладывает никаких ограничений ни то, сколько параметров (и какие) использует планировщик; собственно, именно ради этого их вынесли в userspace.

> Хорошо, управлять можно, но получится deadline или noop планировщик.

Если считать корреляторы, а не только смотреть на мгновенные значения параметров, то получится anticipatory.

> В linux IO планировщики обладают широкими возможностями по управлению потоком данных, а не только приоритетом.

Только весьма небольшого NFS траффика хватает, чтоб они начали вести себя совершенно неадекватно.

> Нет, всего лишь скорость работы одних и тех же IO задач в RT системах и нет.

Да, Вы правы. Вопрос только в том -- а как много задач, где важна _только_ скорость I/O? (вопрос о тормознутости NFS в Linux 2.6.x я пока оставляю в стороне)

> Не нужно ерничать, если ты считаешь, что gcc vs asm тоже самое, что потоки и конечные автоматы вообще и микроядерный планировщик против IO планировщика в linux kernel, то продолжать бессмысленно.

Любой корректный алгоритм можно представить как конечный автомат. Поэтому любой алгоритм можно реализовать на asm'-е ([conditional] jump есть -- что еще надо?). Ан нет, глупые людишки предпочитают пользоваться всякими абстракциями, а заодно -- поручать компилятору проверку правильности использования этих абстракций (a.k.a. типизация). Отказываясь от абстракций, человек берет на себя [тупую] работу компилятора. Монолитный дизайн -- это точно такой же "закат солнца вручную", отсюда и сравнение.

> Mosix - это всего лишь кластерная архитектура. И она отлично подходит для своего круга задач

Херово она справляется со своей задачей, а ее Linux'-овая реализация -- еще хуже. LAM/MPI превосходит ее по производительности в разы. Единственное преимущество -- код, пользующий OpenMP & DSM, гораздо красивее.

> Дело в построении локальной системы, а не кластерного компьютера.

Т.е. тормозную NFS (про knfsd говорить не буду, потому как модераторы все равно удалят за нецензурщину) в 2.6 следует воспринять как должное, про нормальную поддержку NFSv4 и AFS -- даже и мечтать.

> Есть подозрение, что dselect так и не понял, почему микроядерный планировщик с возможностью управления только приоритетом потока (пусть даже сколь угодно нетривиальными алгоритмами) не может и никогда не сможет сравниться и сравниваться с полноценными IO планировашиками

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

> имеющими возможность оценивать поток данных "изнутри".

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

> Дискуссия завершена.

Началась пропаганда учения Маркса^W Линуса про преимущество коммунистического общества^W^W монолитного дизайна.