LINUX.ORG.RU

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


0

0

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

Итак имеем 2-процессорный сервер с обычным генту:

$ uname -a
Linux some_srv 2.6.16.19 #1 SMP Sat Jun 23 19:35:24 MSD 2007 x86_64 Intel(R) Core(TM)2 CPU 6700 @ 2.66GHz GenuineIntel GNU/Linux

Запускаю 3 процесса тупо жрущих CPU.

Имеем:

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
13081 user    25   0  6992  868  740 R  100  0.0   4:48.62 a.out
13080 user    25   0  6988  868  740 R   50  0.0   2:24.87 a.out
13082 user    25   0  6992  868  740 R   50  0.0   2:24.73 a.out

мы видим что одному из процессов тупо отдано в 2 раза больше CPU.
★★★★★

(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 и всё такое)
результаты нормальные, что я делаю не так?

max_posedon
()
Ответ на: комментарий от max_posedon

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

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

dilmah ★★★★★
() автор топика
Ответ на: комментарий от max_posedon

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

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

Что не так?

anonymous
()
Ответ на: комментарий от anonymous

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

dilmah ★★★★★
() автор топика
Ответ на: комментарий от dilmah

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

dilmah ★★★★★
() автор топика

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

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

anonymous
()

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

Legioner ★★★★★
()
Ответ на: комментарий от max_posedon

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

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

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

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

dilmah ★★★★★
() автор топика
Ответ на: комментарий от max_posedon

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

dilmah ★★★★★
() автор топика
Ответ на: комментарий от max_posedon

2dilmah:

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

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

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

Die-Hard ★★★★★
()
Ответ на: комментарий от anonymous

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

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

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

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

dilmah ★★★★★
() автор топика
Ответ на: комментарий от dilmah

2dilmah:

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

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

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

Die-Hard ★★★★★
()
Ответ на: комментарий от dilmah

2dilmah:

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

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

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

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

Die-Hard ★★★★★
()
Ответ на: комментарий от dilmah

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

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

anonymous
()

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

anonymous
()
Ответ на: комментарий от anonymous

anonymous (11.07.2007 20:30:41):

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

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

Die-Hard ★★★★★
()
Ответ на: комментарий от Die-Hard

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

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

anonymous
()
Ответ на: комментарий от dilmah

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

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

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

anonymous
()
Ответ на: комментарий от dilmah

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 сек. Какая цель?

anonymous
()
Ответ на: комментарий от dilmah

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

Pi ★★★★★
()

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

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

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

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

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

anonymous
()
Ответ на: комментарий от dilmah

dilmah:

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

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

Die-Hard ★★★★★
()
Ответ на: комментарий от anonymous

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

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

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

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

Die-Hard ★★★★★
()
Ответ на: комментарий от Die-Hard

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

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 игнорируются переносы строк."

anonymous
()
Ответ на: комментарий от Die-Hard

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

Апшипся.

anonymous
()

Вот обещанные результаты на 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

dilmah ★★★★★
() автор топика
Ответ на: комментарий от vasist

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

:)

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

dilmah ★★★★★
() автор топика
Ответ на: комментарий от vasist

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

Это пять! ROTFL.

anonymous
()
Ответ на: комментарий от dilmah

2dilmah:

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

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

Die-Hard ★★★★★
()
Ответ на: комментарий от anonymous

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

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

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

stassats ★★★★
()
Ответ на: комментарий от dilmah

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

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

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

ival ★★
()
Ответ на: комментарий от ival

2ival:

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

Die-Hard ★★★★★
()
Ответ на: комментарий от dilmah

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

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

DonkeyHot ★★★★★
()
Ответ на: комментарий от dilmah

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

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

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

fmjs
()
Ответ на: комментарий от dilmah

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

yantux
()
Ответ на: комментарий от dilmah

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

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

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

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

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

vasist
()
Ответ на: комментарий от vasist

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

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

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

fmjs
()
Ответ на: комментарий от fmjs

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

fmjs
()
Ответ на: комментарий от fmjs

Результат с 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, двухкорочка.

fmjs
()
Ответ на: комментарий от fmjs

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

fmjs
()
Ответ на: комментарий от anonymous

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

fmjs
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.