Планировщик задач CFS будет включен в состав Linux ядра 2.6.23

back to the multix?

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

а как же интерактивные desktop процессы, где время отклика критично и не-интерактивные long-run процессы, которые и подождать могут?

распредиление 1/n, как в этом ``cfs'' imho худший (но и самый простой) вариант, из того, что можно придумать: и desktop тормозит и вычисления стоят. и чем больше процессов, тем только хуже

чего они там курят в этом `линуксе'?? ж)

Не позорился бы лучше.

Читай подробности, а потом уж языком мели...!

> а как же интерактивные desktop процессы, где время отклика критично и не-интерактивные long-run процессы, которые и подождать могут?

Для этого ешо в камменом веке придумали систему приоритезации :D

>ланировщик задач

мож поправите

Кто нить юзал его? как впечатления?

ты вряд ли заметишь разницу

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

т.е. как в армии -- пусть безобразно, но зато однообразно

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

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

Я его юзаю, сказать честно - ничего не заметил.

gln0fate@localhost:~$ uname -a Linux localhost 2.6.21.5-cfs18-fate #1 PREEMPT Sun Jul 1 14:46:00 MSD 2007 i686 Debian GNU/Linux

Сразу видно, что новость проверял шаман.

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

Ой, если это было так, то у нас бы на курсе за такой планировщик "двойку" влепили бы

что ни говори , а парни иногда любят бросить красивое словцо :
ideal, precise multi-tasking CPU
это уже в который раз идеальное ?
новая фича - p->wait_runtime

Наоборот всё вообще-то. Как раз и сделано, чтобы не критичное к времени выполнения не мешало тому же десктопу.

Насколько я понимаю, будет возможность выбрать и другие планировщики также, как это можно сделать сейчас с cfq/ac/deadline . Если так, то чего раскудахтались? Выберите, что хотите. :)

http://www.linuxinsight.com/files/sched-design-CFS.txt

>Насколько я понимаю, будет возможность выбрать и другие планировщики также, как это можно сделать сейчас с cfq/ac/deadline . Если так, то чего раскудахтались? Выберите, что хотите. :)

Не путайте теплое с мягким. cfq/ac/deadline - планировщики IO

>Не путайте теплое с мягким. cfq/ac/deadline - планировщики IO

Млть, читать умеем? "также, как это можно сделать сейчас с cfq/ac/deadline". Где я ставлю между этими планировщиками знак равенства. Я говорю только о том, что вполне вероятно, что можно будет вот также переключать!

Такой возможности на данный момент нет (во всяком случае гугл мне не помог). Читаю плохо. по слогам

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

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

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

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

угу. и сочинение. чтоб по-русски писали.

Хорошая новоть! RT не загорами!

Кароч, врубать эту штуку на десктопе или не стоит?

Gentoo Linux 2.6.2x (kamikaze-sources), Turion64 X2 2.0GHz, 1GB RAM - vse ok na CFS, ni4ego ne zaikaetsa, quake3 urban terror 4 begaet norm ;)

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

И тогда получим http://www.lrn.ru/

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

>угу. и сочинение. чтоб по-русски писали.

И тогда получим http://www.lrn.ru/

в самом деле:

There is only one central tunable:

/proc/sys/kernel/sched_granularity_ns

which can be used to tune the scheduler from 'desktop' (low latencies) to 'server' (good batching) workloads.

где, по ходу, регулируется размер "единицы распределения".

(см. http://people.redhat.com/mingo/cfs-scheduler/sched-design-CFS.txt)

"я не проверял, но идея хорошая" ;)

>Gentoo Linux 2.6.2x (kamikaze-sources), Turion64 X2 2.0GHz, 1GB RAM - vse ok na CFS, ni4ego ne zaikaetsa, quake3 urban terror 4 begaet norm ;)

Ты бы еще на Earth Simulator quake3 запустил.

CFS это гуд. Я, правда, в lkml не нашёл _явного_ указания, что его замёржат, поскольку народ задумал там и group scheduling заодно приделать, а оно зависит от containers, которые в данный момент активно перерабатываются.

Хм, а он будет вести себя в случае одного процесса, который активно делает IO и другого, который делает большой объём вычислений? Как тогда будет считаться p->wait_runtime ?

Об этом планировщике здесь говорили в апреле месяце, когда бы первый анонс: http://www.linux.org.ru/view-message.jsp?msgid=1886050

>Новель перспективной разработкой с точки зрения увеличения тормознутости для Зюзи?

Кому тут зузя мешает, зачем распускать вопли. Афтар этого поста - сходи в дет. сад или выпей яду. Вывод прост - не нравится - не ставь!

Я зузю юзаю не первый год и очень ею доволен, не то что всякими наколенными дистрами, типа "сделай сам..." :-!

Ponravilsja komment na slashdote:

Kakoj takoj CFS? Scheduler v Linux eto crond!

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=shortlog;h...

>чего они там курят в этом `линуксе'?? ж)

вот и бздуны подтянулись, водоемы газифицировать

Интересный комментарий на ./

a fair scheduler won't help. BeOS had a very snappy, responsive GUI by being multithreaded (each window was a thread) and giving window/display threads higher priority. Even if the CPU(s) were bogged down with other threads, moving windows, the display stayed responsive. X is single threaded and the window manager architecture makes the problem worse. A fair scheduler doesn't help; it actually makes things worse.

Что, неужели правда?

Что говорит сам Ingo Molnar:

(disclaimer, i'm the main author of CFS.)

I'd like to point out that CFS is O(1) too.

With current PID limits the worst-case depth of the rbtree is ~15 [and O(15) == O(1), so execution time has a clear upper bound]. Even with a theoretical system that can have 4 million tasks running at once (!), the rbtree depth would have a maximum of ~20-21.

The "O(1) scheduler" that CFS replaces is O(140) [== O(1)] in theory. (in practice the "number of steps" it takes to schedule is much lower than that, on most platforms.)

So the new scheduler is O(1) too (with a worst-case "number of steps" of 15, if you happen to have 32 thousand tasks running at once(!)), and the main difference is not in the O(1)-ness but in the behavior of the scheduler.

И ещё один комментарий Ingo:

> Seriously? What, the kernel switches to a process, the process checks its environment and figures out that the event it was waiting for hasn't happened yet, and goes back to sleep? I can't believe that a project as mature as the Linux kernel would use a scheduler like that.

No, CFS does not do that, and that would be quite silly to do indeed :-)

CFS keeps tasks that woke up in the runqueue, and allows them to run immediately in the typical case - just like the old scheduler did.

Where CFS differs from the old scheduler is mainly the case when there are more tasks runnable than there are CPUs/cores available. In such cases, on any modern multitasking kernel, the scheduler has to decide which task to run, and in what order and weight to run those tasks, with the goal to provide to the user the happy illusion of multiple, snappy applications running at once.

The old O(1) scheduler decided the "order and weight" of runnable tasks based on an pretty elaborate set of heuristics. The rules are pretty complex, but it mostly boils down to 'sleepers get more CPU time than runners'.

(sidenote: CFS is an O(1) scheduler too for all practical purposes, with an upper limit of ~15 algorithmic steps worst-case)

Now those heuristics worked pretty well for 15 years (those sleep-heuristics were always part of Linux scheduling, the O(1) scheduler i wrote inherited them from the original O(N) scheduler), but good is never good enough in the land of Linux ;-)

How does CFS work? CFS follows an approach similar to Con Kolivas' SD project: a scheduler core that instead of heuristics uses "fair scheduling" to achieve interactivity. Runnable tasks are scheduled in a painstakingly fair way (and that seemingly simple concept alone is pretty hard to achieve in a general purpose kernel).

The simplest case is when there are only CPU-intense tasks running. For example, if there are 8 CPU-intense tasks running on the CPU, each task gets exactly 12.5% CPU time. If you watch how much CPU time the tasks get it will be 12.5% long-term too, with no deviations, with no skewing caused by other tasks running inbetween.

The more complex case is when applications schedule frequently (and that is the case on most desktops and servers), so CFS extends the concept of 'fairness' to sleeping tasks too. CFS accounts not only 'runners', but 'sleepers' too. Tasks that sleep/run frequently are still given their full 'fair share' of the CPU, up to the limit they could have gotten were they not sleeping at all.

So for example, if you have two tasks on a CPU, one a 100% CPU hog, the other one an application that sleeps/runs 50% of the time - both will get 50% of the CPU in CFS. Under the strict 'runner fairness' approach (which for example SD is following), the 100% CPU hog would get ~66% of CPU time, the sleeper would get ~33% of CPU time.

To achieve 'sleeper fairness', CFS runs the (ex-)sleeper task sooner, to offset its disadvantage of not hanging around on the CPU all the time. Or in other words: interactive tasks (tasks that sleep often) will get to the CPU with lower latencies. Which is the holy grail of good desktop scheduling :-)

(granted, CFS does a whole lot more than that, its patch-impact size is 3 times larger than SD. CFS is not a single patch but a series of 50 patches, which also modularize kernel scheduling policy implementation (note, it does not modularize the scheduler itself a'la PlugSched), offer "group scheduling" (nifty thing for containers/virtualization and large systems, written by Srivatsa Vaddagiri of IBM), offer precise CPU usage accounting to /proc (used by CPU/task monitoring tools), and much more. We decided to turn Linux scheduling upside down, which gave me the easy excuse^H^H^H opportunity to extend the scheduler's design a bit more ;-)

> vse ok na CFS, ni4ego ne zaikaetsa, quake3 urban terror 4 begaet norm ;)

они параллельно на одной тачке бегают не заикаясь, или как?

>Насколько я понимаю, будет возможность выбрать и другие планировщики также, как это можно сделать сейчас с cfq/ac/deadline

И это правильно! Одно дело дескоп, другое контент отдавать....

Даешь больше планировщиков с узкой специализацией!!!!

>Такой возможности на данный момент нет (во всяком случае гугл мне не помог).

Да, по ходу дела, это будет единственный планировщик, насколько я понял, но настраиваемый.

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

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

эт кого же интересно на коленках делают? может gentoo, или Debian?? если говоришь - обосновывай

LFS, наверное

QNXкапец приблежается, скоро будут АЭС под управлением Слаки, станки, управляемые красношляпыми, и ракеты под красноглазыми.

> И ещё один комментарий Ingo:

Интересно.

>QNXкапец приблежается, скоро будут АЭС под управлением Слаки, станки, управляемые красношляпыми, и ракеты под красноглазыми

Зря смеешсо, /me только что смотрел на станок с ЧПУ на линухе .. впрочем там вроде только интерфейсная часть на лине.

Всё равно этот шедулер сосёт в сравнении с SD.
Я буду продолжать юзать SD шедулер Кона.

блин, сколько уже там этих планировщиков??