Планировщик задач, Linux.

[desperado]

Подкиньте ссылочку, кто знает, как работает сабж, желательно на русском.

 

в первую очередь интересует, могут ли мигрировать задачи между процессорами, и как он их распределяет. Например что будет если будет выполняться 10 процессов и все они после запуска окажутся на одном ядре в условиях дефицита процессорного времени? перекинет ли он их на другое ядро? возможно ли это в принципе? можно ли этим управлять из программы?

Edited October 20, 2007 by desperado

[Kirya]

Все зависит от того, какой shwduler стоит.

Привязывать процессы к конкретному ядру можно.

Читай документацию, её много.

В первую очередь Documentation в сорцах ядра.

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

Edited October 20, 2007 by Kirya

[edo]

Например что будет если будет выполняться 10 процессов и все они после запуска окажутся на одном ядре в условиях дефицита процессорного времени?

у вас что-то типа девяти женщин, рожающих ребенка за месяц получилось ;)

 

одновременно каждое ядро может выполнять не более одного процесса.

планировщик периодически просмаривает список процессов, готовых выполняться, и распределяет их по ядрам.

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

 

у нас M процессов, готовых выполняться, и N ядер

1. M=N

на каждом ядре будет запущен свой процесс

2. M>N

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

3. M<N

часть ядер простаивает

 

вдогонку - ничего linux-специфичного тут нет, afaik все многозадачные операционные системы устроены так.

[nuclearcat]

На английском, т.к. пользуюсь только оригинальными ресурсами

http://josh.trancesoftware.com/linux/linux_cpu_scheduler.pdf

инфа по ядрам до-CFS эры

 

И еще

http://www.oreilly.com/catalog/linuxkernel/chapter/ch10.html

[desperado]

Всем спасибо за инфу и ссылки!

 

буду осваивать доки.

 

edo

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

 

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

Edited October 20, 2007 by desperado

[nuclearcat]

Вот свежее сообщение в kerneltrap

"Currently in mainline the balancing of multiple RT threads is quite broken. That is to say that a high priority thread that is scheduled on a CPU with a higher priority thread, may need to unnecessarily wait while it can easily run on another CPU that's running a lower priority thread," began Steven Rostedt, describing his patchset to introduce improved real time task balancing. He explained:

 

"Balancing (or migrating) tasks in general is an art. Lots of considerations must be taken into account. Cache lines, NUMA and more. This is true with general processes which expect high through put and migration can be done in batch. But when it comes to RT tasks, we really need to put them off to a CPU that they can run on as soon as possible. Even if it means a bit of cache line flushing. Right now an RT task can wait several milliseconds before it gets scheduled to run. And perhaps even longer. The migration thread is not fast enough to take care of RT tasks."

 

Steven described his test cases and numerous issues he noticed with the current balancing code, noting, "to solve this issue, I've changed the RT task balancing from a passive method (migration thread) to an active method. This new method is to actively push or pull RT tasks when they are woken up or scheduled."

[Egor]

НЯЗ, по возможности, шедулер пытается один и тот же поток на одном и том же ядре запускать, для лучшей когерентности кэшей. Но именно всего лишь по возможности. Если нагрузка на ядро большая, то может спихнуть на другое не поморщившись.)