Планировщик задач с полностью справедливым распределением ресурсов CFS (Completely Fair Scheduler), после трех месяцев обкатки в экспериментальной "-mm" ветке Linux ядра, включен в состав (http://www.linuxinsight.com/cfs-scheduler-to-appear-in-linux...) ядра 2.6.23, в качестве основного планировщика.
В планировщике задач CFS вместо очередей процессов ожидающих выполнения, используется дерево rbtree, определяющее план с временем перехода к выполнению очередного процесса. Единица планирования времени в CFS фиксирована - наносекунда, и не привязана к частоте генерации прерываний таймера (HZ).
CFS планировщик поддерживает два режима работы: 'desktop' (low latencies) и 'server' (good batching).
URL: http://www.linuxinsight.com/cfs-scheduler-to-appear-in-linux...
Новость: https://www.opennet.ru/opennews/art.shtml?num=11356
что-то у меня не сходится, поясните невежде
сказано:
> Единица планирования времени в CFS фиксирована - наносекунда
на 3GHz процессоре за 1-у наносекунду проходит 3 такта, учитывая что даже чтение из памяти может занять несколько десятков тактов, а за один такт точно не делается больше одной опарации ( во всяком случае на х86 ), то как можно планировать каждую наносекунду?
я так понимаю, это для того, чтобы оставить задел на будущее - серастет сейчас в основном не частота процессоров, а количество ядер.
клавиатура сглючила. :)
так вот. в основном растет не частота процессоров, а количество ядер. И видимо легче отталкиваться от временного промежутка, чем от частоты.
Хотя все это конечно ИМХО
А кто что-то сказал, про конкретный порядок количества, измеряемого этой единицей измерения?
Кто сказал, что есть возможность, к примеру, задать 3 наносекунды для длительности чего-либо?>> Единица планирования времени в CFS фиксирована - наносекунда
>на 3GHz процессоре за 1-у наносекунду проходит 3 такта, учитывая что даже
>чтение из памяти может занять несколько десятков тактов, а за один
>такт точно не делается больше одной опарации ( во всяком случае
>на х86 ), то как можно планировать каждую наносекунду?
> ,,, а за один такт точно не делается больше одной опарации...
Да, вроде, давно уже делается. На Интелах, по крайней мере.
> как можно планировать каждую наносекунду?легко.
вообще, разрешающая способность шедулера ограничиваеться разрешением таймера, прерываниями которого могут ограничиваться слайсы работы процессов.т.е. неважно сколько инструкций выполнил процесс за отведенный ему слайс в минимум одну наносекудну: хоть 1, хоть 3, хоть 500 (ну, через пиццот лет :) - при прерывании таймера управление может быть передано другому процессу.
кстати, выражения "Единица планирования времени в CFS фиксирована - наносекунда"
и "как можно планировать каждую наносекунду?" не приведены к общему знаменателю :)
т.е. говорят о разных вещах.
Те. первая утверждает, что результатом работы шедулера будет _количество_ наносекунд, выданное какому-либо процессу.
Вторая робко надееться, что каждая наносекунда работы процессора будет точно расписана :)
Ессьно, этого не будет. Сам шедулер _может_ работать больше наносекунды (если конечно нужно и частота проца достаточно низка). Просто на его выходе будет цыфра в наносекундах.
n CFS this fairness imbalance is expressed and tracked via the per-task p->wait_runtime (nanosec-unit) value. "wait_runtime" is the amount of time the task should now run on the CPU for it to become completely fair and balanced.Wrong translation
Вот интересно - его намернво заменять, или можно будет выбрать между несколькими вариантами?
И как бы тоже крайне интересно - почему все упираются в наносекунду?
Это просто точность шедулера наносекунда. А задания которые будут находиться в состоянии ожидания, состояния выполнения,обработчики нижних и верхних половин и програмные прерывания будут более рационально использовать время, пусть даже одного ядра.
А кто вообще писал новость?
На rbtree перешли уже давно, с ядра так эдак 2.6.10, об этом Роберт лав писал в книжке. Или у разработчиков ядра уже дежавю :-)
дополните и поправте если я заблуждаюсь, преключение контекста задачи
1 чем больше за единицу времени тем лучше? (плавность перехода) и хреново меньше попаданий в кешь ЦПУ растут задержки при обращении к памяти общее снижение производительности2 чем меньше за единицу времени тем лучше?
>дополните и поправте если я заблуждаюсь, преключение контекста задачи
>1 чем больше за единицу времени тем лучше? (плавность перехода) и
>хреново меньше попаданий в кешь ЦПУ растут задержки при обращении к
>памяти общее снижение производительности
>
>2 чем меньше за единицу времени тем лучше?тут все просто: переключение - это уже работа, на которую уходит время.
Ну и про кеш ты правильно сказал.
Больше переключений - сильнее иллюзия многозадачности и выше скорость реакции.Но факт фактом: скорость и интерактивность - на разных чашах весов.
1) - не совсем так, все зависит от систему (сервер, рабочая станция). По принципу мышления, если за кэшем не следить, то падает производительность, но ядро следит за кэшем и поддерживает его в актуальном состоянии + у проца есть предсказание переходов и ветвлений. Если сравнить скорость обмена с памятью и кэшем 2 уровня - скорость раза в два меньше.
2) - в планировщике задач это оптимизированно, и перестаривается в процессе работы.
c CFS понятно, а что с SD (бывший RSDL) будет? Более правильным решением было бы конечно включению в основную ветку ядра обоих новых планировщиков и дать юзверю (то есть мне) уже выбрать... А вообще, - хорошая тенденция.
Планирование заданий