про шедулер линукса

(cat /dev/urandom > /dev/null)

28856 max_pose 25 0 2680 536 460 R 76 0.1 2:28.13 cat
28850 max_pose 25 0 2680 540 460 R 44 0.1 2:29.39 cat
28852 max_pose 25 0 2684 536 460 R 44 0.1 2:38.04 cat

uname -a
Linux ________ 2.6.21-suspend2-r4 #1 SMP PREEMPT Mon May 21 13:21:03 EEST 2007 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz GenuineIntel GNU/Linux

(обычный Gentoo и всё такое)
результаты нормальные, что я делаю не так?

> результаты нормальные, что я делаю не так?

элементарно Ватсон. У вас 4 процессора и 3 процесса -- да он их все раскидывает по 100% на каждый. Сделай 5 процессов.

Не очень понятно что ты хочешь получить.

не представляю как по другому. 1 процесс на одном процессоре и 2 на другом и делятся процессор поровну.

Что не так?

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

я вечером сделаю тест на 2-х процессорной машине под НетБСД, почему-то у меня ощущение что там сделано правильно

>Эта вещь пошла в >мою копилку доказательств что линукс пионерская поделка..

Результат того-же эксперимента с виндой и бзд в студию...

у меня 2 процессора

cat /proc/cpuinfo | grep processor
processor : 0
processor : 1

повторю вопрос:
что я делаю не так?

Работает. Криминала впрочем не вижу.

так ты хоть поясни чего ты хочешь в итоге добиться?

как по твоему должно быть?

> у меня 2 процессора. повторю вопрос: что я делаю не так?

ну одна из вещей -- это твой тест: (cat /dev/urandom > /dev/null)

Это грязный тест. Он грузит систему а не юзерспейс. И он зависит от имплементации /dev/urandom -- который потенциально может содержать локи (потому что ему нужно обновлять состояние генератора). используй: (while true $((++i)); do true; done)

Впрочем твой тест работает и у меня. Значит у тебя либо наслаиваются какие-то фишки с гипертредингом, либо в твоем ядре это уже пофиксили.

Ой, извини, не тебе. :)

dilmah - расскажи как ты считаеш должно быть правильно? :)

> как по твоему должно быть?

это мне вопрос? Я хочу чтобы accumulated time у всех трех процессов после прошествия некоторого времени, был приблизительно одинаков, а не отличался двукратно.

Я долго пытался понять как это можно сделать на двух процессорах. У тебя включен НТ?

2dilmah:

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

2max_posedon: Наверно дело в том, что в Gentoo ядро собрано с CONFIG_PREEMPT=y. Это немного тормозит общую производительность, вообще-то.

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

> У тебя включен НТ?

у меня core duo, у max_poseidon видимо HT

> Я долго пытался понять как это можно сделать на двух процессорах.

ну просто не нужно аффинити ставить во главу угла. Нужно периодически перекидывать процессы с одного процессора на другой.

2dilmah:

Это еще что! :-)

Ты попробуй перенайсить "шустрый" процесс на, скажем, 19! Хреном по лбу, все равно останется на том же процессоре и будет его кушать!

А вот если его усыпить на секунду и снова разбудить (SIGSTOP SIGCONT), то он мигрирует и станет работать в соответствии с найсом.

2dilmah:

> Нужно периодически перекидывать процессы с одного процессора на другой.

Не нужно этого делать с "сильножрущими" процессами!

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

Во-вторых, миграцию в таких случаях лучше вообще отключать, особенно на НУМА.

Мне кажется, что шедулер не "перекидывает" процесс потому, что "считает" - "перекидывание" процесса (Ping-Pong affinity)будет в итоге стоить дороже чем если оставить все как есть.

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

Я бы посоветовал автору немного подучить матчасть.

anonymous (11.07.2007 20:30:41):

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

Верно. Умолчательный шедулер хочет, чтобы процессор не простаивал, и все. Он же не знает, что на нем бенчмарки гоняют! Он хочет по максимуму загрузить все процессоры. А миграция стОит дорого.

Да, я еще не понял разницу результатов тестов в постах автора и max_posedon.

У max_posedon ситуация аналогична дилмах.

> Нужно периодически перекидывать процессы с одного процессора на другой.

За такое руки и яйца отрывают. Кэш засрать - это дело непростое и долгое, если постоянно это придётся повторять, то производительсность адски просядет, как если бы кэша не было вообще.

Можно вопрос? Ты - одминчег, да? Высокопроизводительными вычислениями ведь никогда не занимался, да?

перекинуть хотя бы раз в полминуты это тяжелый удар по производительности?

http://www.ibm.com/developerworks/linux/library/l-scheduler/

To maintain a balanced workload across CPUs, work can be redistributed, taking work from an overloaded CPU and giving it to an underloaded one. The Linux 2.6 scheduler provides this functionality by using load balancing. Every 200ms, a processor checks to see whether the CPU loads are unbalanced; if they are, the processor performs a cross-CPU balancing of tasks.

A negative aspect of this process is that the new CPU's cache is cold for a migrated task (needing to pull its data into the cache).

Remember that a CPU's cache is local (on-chip) memory that offers fast access over the system's memory. If a task is executed on a CPU, and data associated with the task is brought into the CPU's local cache, it's considered hot. If no data for a task is located in the CPU's local cache, then for this task, the cache is considered cold.

Все упирается в кеш процессора.

Но если честно я так и не уловил зачем перебрасывать процессы раз в 30 сек. Какая цель?

я ох как не силён в этом деле, но понятие "раз в полминуты" примерно соотвествуе "каравай вот такой вот ширины". не каждый процесс живёт столько, а шедулеру всё равно

Только что накатал ответ на стертое сообщение:

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

Распределение ресурсов: 1. Шедуллер не знает какая задача выполнится раньше, какая позже. 2. 3 процесса на 2 процессора. на одном любом процессоре всегда будет 2 процесса которые выполняются "последовательно". 3. Распределение по принципу ФИФО (при равных приоритетах). 4. Миграция "стоит времени и ресурсов".

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

Конкретная ситуация - миграция процессов с процессора на процессор - зачем она?

dilmah:

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

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

anonymous (*) (11.07.2007 21:59:38):

> Конкретная ситуация - миграция процессов с процессора на процессор - зачем она?

Ну я ж приводил пример!

Ты ренайсишь процесс куда-то за 20, а он жрет 99% ЦПУ, в то время других два процесса с нулевым найсом получают каждый менее 50%. Очевидно, это не то, что должно быть!

проблема ясна - автор админ

Попробывал повторить в лоб:

3 команды "cat /dev/urandom &> /dev/null"

дальше: renice 20 -p 21340 && renice 5 -p 21343

имеем:

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 21342 sash 25 0 2804 596 504 R 52.9 0.1 0:53.32 cat 21343 sash 30 5 2804 596 504 R 40.2 0.1 0:48.22 cat 21340 sash 39 19 2804 596 504 R 2.7 0.1 0:18.91 cat

sash@sash-laptop:~$ uname -a Linux sash-laptop 2.6.20-11-lowlatency #2 SMP PREEMPT Thu Mar 15 08:06:06 UTC 2007 i686 GNU/Linux Ubuntu 7.04

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 21342 sash 25 0 2804 596 504 R 52.9 0.1 0:53.32 cat 21343 sash 30 5 2804 596 504 R 40.2 0.1 0:48.22 cat 21340 sash 39 19 2804 596 504 R 2.7 0.1 0:18.91 cat

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
21342 sash 25 0 2804 596 504 R 52.9 0.1 0:53.32 cat
21343 sash 30 5 2804 596 504 R 40.2 0.1 0:48.22 cat
21340 sash 39 19 2804 596 504 R 2.7 0.1 0:18.91 cat

Сорри не заметил - "В режиме Tex paragraphs игнорируются переносы строк."

Хотя да - это на одном процессоре.

Апшипся.

Вот обещанные результаты на 2-х процессорнике под НетБСД:

load averages:  2.89,  1.32,  0.59                                                                                   
73 processes:  2 runnable, 69 sleeping, 2 on processor
CPU0 states:  100% user,  0.0% nice,  0.0% system,  0.0% interrupt,  0.0% idle
CPU1 states:  100% user,  0.0% nice,  0.0% system,  0.0% interrupt,  0.0% idle
  PID USERNAME PRI NICE   SIZE   RES STATE      TIME   WCPU    CPU COMMAND
29928 user      63    0  2276K  860K RUN/0      1:45 65.30% 65.28% ksh
10952 user      63    0  2276K  860K RUN/0      1:42 65.16% 65.14% ksh
24767 user      63    0  2276K  852K CPU/1      1:45 64.92% 64.89% ksh

> проблема ясна - автор админ

:)

ответ ясен: ну пацан до Линукса дорвался... (c) Pi (27.11.2006 23:02:58)

> проблема ясна - автор админ

Это пять! ROTFL.

2dilmah:

Ну, насколько я понимаю, max_posedon продемонстрировал, что под умолчательным Gentooшным ядром будет то же самое.

Вопрос о том, хорошо это или плохо -- весьма спорный. Я не вижу причины, почему это хорошо.

> Да, я еще не понял разницу результатов тестов в постах автора и max_posedon.

> У max_posedon ситуация аналогична дилмах.

Взгляни на скушанное процессорное время.

>Но в исторической перспективе большей нескольких секунд, шедулер должен >справедливо давать CPU, то есть перераспределять процессы.

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

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

2ival:

Нет, там данные не по загрузке процов, а по времени, проведенном процессом на ЦПУ. Это интегральная характеристика.

>Но в исторической перспективе большей нескольких секунд, шедулер должен справедливо давать CPU

Компютеры строют не для отстаивания идеи абсолютной справедливости, а для побыстрее посчитать. Приведеное поведение оптимально для этой цели, с точки зрения данных, доступных планировщику.

> Вот обещанные результаты на 2-х процессорнике под НетБСД:

Получается, что в NetBSD шедулер кривой, если верить местной шпане :)

2ALL: 100% использование аппаратных ресурсов далеко не всегда столь важно, как многим кажется, не надо таким однобоким образом смотреть на ситуацию, существует дофигища критериев, которые могут быть важными, а могут и не быть важными в той или иной ситуации.

Тема интересная. Задайте вопрос на http://qnx.org.ru , как поведёт себя qnx. Может кто и протестирует.

>ответ ясен: ну пацан до Линукса дорвался... (c) Pi (27.11.2006 23:02:58)

и что дальше?? :)

имхо в данной ситуации (50 50 100) нет ничего криминального, всё очень даже законно

с чего это вдруг планировщику перекидывать процесс на другой проц? он распределяет два первых процесса на разные процы, а оставшийся процесс идёт на первый попавшийся проц, это очень даже логично. Почему не перекидывает переодически? А нафига? какой от этого прирост в скорости? Никакого! Впрочем всё это уже было так или иначе сказано выше.

В чём проблема? Я не пойму...

> имхо в данной ситуации (50 50 100) нет ничего криминального, всё очень даже законно

данная ситуация не согласуется с определением time sharing политики планирования дефолтной, которая гласит "активным процессам с равними приоритетами должно уделятся равное время".

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

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

Вообще-то NetBSD известна своей отвратительной поддержкой SMP, глобальную блокировку там по-моему только недавно убрали, так что...

> Вообще-то NetBSD известна своей отвратительной поддержкой SMP, глобальную блокировку там по-моему только недавно убрали, так что...

NetBSD, да, известна, а Linux известен своими красноглазиками.

Результат с OS X, вполне адекватно работающей на SMP: 

Processes:  67 total, 5 running, 62 sleeping... 191 threads            12:45:48
Load Avg:  0.67, 0.19, 0.06     CPU usage:  96.8% user, 3.2% sys, 0.0% idle
SharedLibs: num =  160, resident = 34.8M code, 5.79M data, 13.3M LinkEdit
MemRegions: num =  4380, resident = 67.9M + 20.4M private, 99.7M shared
PhysMem:   165M wired,  159M active,  207M inactive,  532M used,  491M free
VM: 6.65G +  106M   27664(0) pageins, 0(0) pageouts

  PID COMMAND      %CPU   TIME   #TH #PRTS #MREGS RPRVT  RSHRD  RSIZE  VSIZE
  494 1           64.8%  0:07.68   1     8    15  12.0K   788K   244K  26.6M
  496 1           63.9%  0:07.73   1     8    15  12.0K   788K   264K  26.6M
  495 1           62.8%  0:07.74   1     8    15  12.0K   788K   264K  26.6M


Машина - Intel Core Duo, двухкорочка.

К сожалению 4х процессорная машина пока занята, так-бы на ней погонял 5-6 поточный тест.

И вообще, эта самая "отвратительная поддержка SMP" к шедулеру никак не относится. Отвратительная поддержка это: сетевой стек не рассчитанный на работу в SMP окружении, глобльно блокируемая VFS, итп. Приведенные тесты ничего подобного не используют.