[image]

Почему ядра не загружены равномерно?

 
1 2 3 4 5 6
US Сергей-4030 #10.01.2012 23:25  @TheFreeMan#10.01.2012 22:08
+
+2
-
edit
 

Сергей-4030

исключающий третье
★★
TheFreeMan> Scheduler Windows (и Linux тоже) не делает разницы между релаьными и виртуальными ядрами.
TheFreeMan> Строго говоря, когда влючен HT то реальных ядер вообще нет, есть только виртуальные.
TheFreeMan> Если отключить HT, то будут только реальные.
TheFreeMan> Насчет самого топика, напишите программу которая запускает 2 потока которые исполняют while(1).
TheFreeMan> Будут загружены 2 ядра из 4-х. Надо обьяснять почему ?

В данном случае у нас не 2 треда, а, как легко видеть, 1041.

И вообще, вопрос исчерпан. По данной Никите ссылке, Windows знает, какие ядра "виртуальные". Вернее, скорее всего, знает, какая пара "виртуальных" сидит на одном "реальном". И дальше действует в соответствии. Т.е, скажем, у нас такая раскладка:

Ядро 1-2 - на "реальном" №1
Ядро 3-4 - на "реальном" №2
Ядро 5-6 - на "реальном" №3
Ядро 7-8 - на "реальном" №4

Загрузка такая:
1, 4, 5, 8 - 75%
2, 3, 6, 7 - 0%

Что такое 75%? Это, по большому счету, значит вот что: в данный момент вероятность застать ядро свободным равна 1/4. Конечно, у нас есть всякие очереди и т.п, но если у нас общая нагрузка на процессоры низка, очереди на выполнение практически пусты / процессы в состоянии ожидания.

Теперь мы пытаемся выполнить тред. Винда видит, что 1-2 - на одном и том же "реальном" ядре и понимает, что не имеет смысла выдавать на ядро 2 пока ядро 1 не занято. Потому, что хотя HT сделает переключение контекста быстрее, чем ОС, но не делать переключение - еще быстрее. Итак, винда сначала пытается найти свободное "реальное" ядро и с вероятностью 1-(3/4)4 его находит. Иначе выдает исполнение на "несвободное".

ЗЫ Я понимаю, что в реальности scheduler куда сложнее, я иллюстрирую принцип.
   16.0.912.7516.0.912.75
IL TheFreeMan #10.01.2012 23:26  @Mishka#10.01.2012 23:21
+
-1
-
edit
 

TheFreeMan

втянувшийся

Mishka> Нет. Если есть поддержка HT в ОС, то не будет.
В смысле ОС решит для себя какой главный а какокй нет ? Тогда да.
Просто нету такой комманды на ассемблере которая скажет это "главныи" или вспомагательный hardware thread.

Mishka> Тоже проблемы с реляциями?
Не понял вопроса.
   16.0.912.7516.0.912.75
US Сергей-4030 #10.01.2012 23:27  @Mishka#10.01.2012 23:24
+
-
edit
 

Сергей-4030

исключающий третье
★★
Mishka> Там, насколько я понимаю, очереди с приоритетами. Если два потока принадлежат одному ядру, то одному присваивается приоритет повыше, а другому пониже. Ядра всегда сначала беруться из очереди с более высоким приоритетом. И обход очередей не включает "формулу справедливости".

Вроде было упоминание, что ID ядер присваиваются с учетом HT.
   16.0.912.7516.0.912.75
US Mishka #10.01.2012 23:27  @TheFreeMan#10.01.2012 23:20
+
+1
-
edit
 

Mishka

модератор
★★★
TheFreeMan> К чему это всё ?

Это к тому, как HT инициализируется.

TheFreeMan> Можно например увидеть где там идет речь о "Если HT врублен, то одно будет использоваться, как реальное, а другое, как дополнение".

Это дело ОСи и каждая ОС работает по своему. В лине ты можешь посмотреть в исходники. В частности можешь полазить по ним и поискать фразы soft affinity и hard affinity. Там недалеко будет, ЕМНИП и работа с HT.

TheFreeMan> с точки зреня софта, когда включен HT, то два "hardware threads" на одном ядре абсолютно равнозначны.

Нет.
   7.0.17.0.1
US Сергей-4030 #10.01.2012 23:28  @TheFreeMan#10.01.2012 23:26
+
+1
-
edit
 

Сергей-4030

исключающий третье
★★
TheFreeMan> Просто нету такой комманды на ассемблере которая скажет это "главныи" или вспомагательный hardware thread.

Для приложения - нету, для ОС - есть. В том смысле, что ОС "знает" приоритет, - согласно рекомендованным спецификациям.
   16.0.912.7516.0.912.75
US Mishka #10.01.2012 23:29  @Сергей-4030#10.01.2012 23:27
+
-
edit
 

Mishka

модератор
★★★
Сергей-4030> Вроде было упоминание, что ID ядер присваиваются с учетом HT.
Да, есть такое требование, ЕМНИП, при ACPI поддержке. В документе по инициализации многоядерных систем (а HT инициализация выполняется по ним) есть и структура этого блока, и требования, и прочее.

Ссылку на описание блоков инициализации процессоров я привёл выше.
   7.0.17.0.1
IL TheFreeMan #10.01.2012 23:31  @Сергей-4030#10.01.2012 23:28
+
-1
-
edit
 

TheFreeMan

втянувшийся

Сергей-4030> Для приложения - нету, для ОС - есть.
Я же попросил на ассемблере. :-)

Сергей-4030> В том смысле, что ОС "знает" приоритет, - согласно рекомендованным спецификациям.
Нет, мы таких спецификаций не даём. :-)
   16.0.912.7516.0.912.75
US Сергей-4030 #10.01.2012 23:33  @Mishka#10.01.2012 23:27
+
-
edit
 

Сергей-4030

исключающий третье
★★
TheFreeMan>> с точки зреня софта, когда включен HT, то два "hardware threads" на одном ядре абсолютно равнозначны.
Mishka> Нет.

Миша, я могу ошибаться, но по-моему, так. Из всего, что я смотрел, единственная информация, которая передается ОС - это "приоритет" ядер. То есть, видимо, дело обстоит так: скажем, у нас два "реальных" ядра, причем включен HT. Железо эмулирует 4 виртуальных ядра:

A, B - на первом "реальном"
C, D - на втором "реальном".

После этого, железо передает информацию о процессорах следующим образом:

1 - A
2 - C
3 - B
4 - D

Вот только на основании этого Винда будет сначала загружать A. Он ничуть не более "реален", чем B, но тем не менее, такая стратегия приведет к тому, что загрузка обоих "реальных" ядер одинакова.
   16.0.912.7516.0.912.75
IL TheFreeMan #10.01.2012 23:33  @Mishka#10.01.2012 23:27
+
-
edit
 

TheFreeMan

втянувшийся

TheFreeMan>> с точки зреня софта, когда включен HT, то два "hardware threads" на одном ядре абсолютно равнозначны.
Mishka> Нет.

Да. (иначе ссылку на Intel где говорится о "главном" и "вспомогательном")
   16.0.912.7516.0.912.75
US Mishka #10.01.2012 23:34  @TheFreeMan#10.01.2012 23:26
+
-
edit
 

Mishka

модератор
★★★
TheFreeMan> Не понял вопроса.
Важно знание, что две нитки на одном проце. Нитки симметричны с точки зрения железячной имплементации. Кого назначить главным, а кого подчинённым в этой паре, не важно. Плюём в потолок и назначаем. Важно, что нагрузка на оба в паре может привести к замедлению. Поэтому, пока ресурсы есть, пользуем главных, как нет, так начинаем привахивать.

Реляционная алгебра здесь при том, что задана пара (а1,а2) — реляция; и она равна паре (а2,а1) — симметрия. Порядок в паре назначаем произвольно.
   7.0.17.0.1
US Сергей-4030 #10.01.2012 23:37  @TheFreeMan#10.01.2012 23:31
+
+1
-
edit
 

Сергей-4030

исключающий третье
★★
Сергей-4030>> Для приложения - нету, для ОС - есть.
TheFreeMan> Я же попросил на ассемблере. :-)

Да чего там на ассемблере, просто в registry - Device Instance Id.

Сергей-4030>> В том смысле, что ОС "знает" приоритет, - согласно рекомендованным спецификациям.
TheFreeMan> Нет, мы таких спецификаций не даём. :-)

Intel's recommendation is to list the first logical processor on each of the physical HT processors before listing any of the second logical processors.
 
   16.0.912.7516.0.912.75
IL TheFreeMan #10.01.2012 23:37  @Сергей-4030#10.01.2012 23:27
+
-1
-
edit
 

TheFreeMan

втянувшийся

Сергей-4030> Вроде было упоминание, что ID ядер присваиваются с учетом HT.

Я там выше приводил реальный алгоритм работы Windows scheduler.
Приоритеты даются software threads, у hardware threads нет приоритетов.
   16.0.912.7516.0.912.75
US Сергей-4030 #10.01.2012 23:39  @TheFreeMan#10.01.2012 23:37
+
+1
-
edit
 

Сергей-4030

исключающий третье
★★
TheFreeMan> Приоритеты даются software threads, у hardware threads нет приоритетов.

Зато у ядра есть номер.
   16.0.912.7516.0.912.75
IL TheFreeMan #10.01.2012 23:41  @Mishka#10.01.2012 23:34
+
-
edit
 

TheFreeMan

втянувшийся

Mishka> Реляционная алгебра здесь при том, что задана пара (а1,а2) — реляция; и она равна паре (а2,а1) — симметрия. Порядок в паре назначаем произвольно.

Здесь согласен, но это ни как не отрицает то что я написал.
Это ОС "решает" кто главный.
   16.0.912.7516.0.912.75
US Mishka #10.01.2012 23:41  @TheFreeMan#10.01.2012 23:33
+
-
edit
 

Mishka

модератор
★★★
TheFreeMan> Да. (иначе ссылку на Intel где говорится о "главном" и "вспомогательном")
Блин, это не дело Интеля. Это дело ОС. Интель говорит, что есть ситуации, когда загрузка обеих в паре приводит к замедлению. Поддержка ОСью HT и означает попыток избежать таких ситуаций. Избежать не всегда удаётся. Ещё раз приведу примеры с рендерингом — если программка видит 8 ядер, то она запустит 8 потоков с убойной целочисленной арифметикой (данные разные, исполнение не сихронизовано до определённых точек). В результате на 4 ядерном проце все нитки (попарно) будут конкурировать за одни и те же ресурсы, что приведёт к тому, что внутри ядра будет задействован механизм разрешения конфликтов. Буквально на всём протяжении timeslice. Т.е. будут большие издержки. А ОС ничего не может сделать — для неё есть 8 потоков, которые свой timeslice отрабатывают по полной, и она честно исчерпав 4 главных, начинает использовать 4 не главных. Поэтому на таких задачах рекомендуют ручками вырубить HT (на ходу не получаются, надо проц сбрасывать), чтобы задачка запускала только 4 нити. Они тогда выполняются без конкуренции и все издержки улетают. Получается быстрее.
   7.0.17.0.1
US Mishka #10.01.2012 23:42  @TheFreeMan#10.01.2012 23:41
+
+1
-
edit
 

Mishka

модератор
★★★
TheFreeMan> Здесь согласен, но это ни как не отрицает то что я написал.
TheFreeMan> Это ОС "решает" кто главный.
Да, ОС. Важно то, что ОС умеет определять такие отношения. Поэтому и говорят, что ОС знает, кто главный. Она сама и назначила.
   7.0.17.0.1
US Сергей-4030 #10.01.2012 23:42  @TheFreeMan#10.01.2012 23:41
+
+1
-
edit
 

Сергей-4030

исключающий третье
★★
TheFreeMan> Это ОС "решает" кто главный.

Никто вроде и не отрицал. Но решает не наобум. Вернее, как минимум, Win 2003 решает не наобум.
   16.0.912.7516.0.912.75
IL TheFreeMan #10.01.2012 23:44  @Mishka#10.01.2012 23:41
+
-1
-
edit
 

TheFreeMan

втянувшийся

TheFreeMan>> Да. (иначе ссылку на Intel где говорится о "главном" и "вспомогательном")
Mishka> Блин, это не дело Интеля. Это дело ОС. ....

Полностью согласен. :-)
Но это не имеет отношения к тому что я писАл.
   16.0.912.7516.0.912.75
US Mishka #10.01.2012 23:44  @TheFreeMan#10.01.2012 23:37
+
+1
-
edit
 

Mishka

модератор
★★★
TheFreeMan> Приоритеты даются software threads, у hardware threads нет приоритетов.
Считай, что порядок в таблице и есть приоритет. :P Вот первые в таблице — главные. А вторые — подчинённые. Или наоборот.
   7.0.17.0.1
US Сергей-4030 #10.01.2012 23:45  @Mishka#10.01.2012 23:41
+
-
edit
 

Сергей-4030

исключающий третье
★★
Mishka> если программка видит 8 ядер, то она запустит 8 потоков с убойной целочисленной арифметикой (данные разные, исполнение не сихронизовано до определённых точек). В результате на 4 ядерном проце все нитки (попарно) будут конкурировать за одни и те же ресурсы, что приведёт к тому, что внутри ядра будет задействован механизм разрешения конфликтов. Буквально на всём протяжении timeslice. Т.е. будут большие издержки. А ОС ничего не может сделать

Ну, в данном случае она ничего и не должна делать. Переключение контекста на уровне ОС медленнее, чем на уровне HT, а знать, что процессы будут очень сильно interlocked ОС не может.
   16.0.912.7516.0.912.75
IL TheFreeMan #10.01.2012 23:47  @Сергей-4030#10.01.2012 23:42
+
+1
-
edit
 

TheFreeMan

втянувшийся

Сергей-4030> Никто вроде и не отрицал. Но решает не наобум. Вернее, как минимум, Win 2003 решает не наобум.

С точки зрения внутренней логики Intel CPU, hardware threads на одно ядре абсолютно равнозначны.
Вот что я хотел с самого начала сказать. :-)
   16.0.912.7516.0.912.75
US Mishka #10.01.2012 23:50  @TheFreeMan#10.01.2012 23:44
+
+1
-
edit
 

Mishka

модератор
★★★
TheFreeMan> Но это не имеет отношения к тому что я писАл.
Это твоё первое сообщение в теме:
TheFreeMan> Scheduler Windows (и Linux тоже) не делает разницы между релаьными и виртуальными ядрами.
И, как выяснили, делает. Для реальных всё пофиг, а для виртуальных — разбито на пары и назначение на проц идёт преимущественно на один из пары. Этот один и выбирается ОС и таким остаётся на всё время работы ОС.
   7.0.17.0.1
US Сергей-4030 #10.01.2012 23:50  @TheFreeMan#10.01.2012 23:47
+
+1
-
edit
 

Сергей-4030

исключающий третье
★★
Сергей-4030>> Никто вроде и не отрицал. Но решает не наобум. Вернее, как минимум, Win 2003 решает не наобум.
TheFreeMan> С точки зрения внутренней логики Intel CPU, hardware threads на одно ядре абсолютно равнозначны.
TheFreeMan> Вот что я хотел с самого начала сказать. :-)

Да, я согласен, это важное уточнение. Когда начались разговоры о "реальных" ядрах, которые загружаются сначала, а потом уж "виртуальные" вход идут, мне было как-то некомфортно. Ваше уточнение валидное.
   16.0.912.7516.0.912.75
US Mishka #10.01.2012 23:51  @Сергей-4030#10.01.2012 23:45
+
-
edit
 

Mishka

модератор
★★★
Сергей-4030> Ну, в данном случае она ничего и не должна делать. Переключение контекста на уровне ОС медленнее, чем на уровне HT, а знать, что процессы будут очень сильно interlocked ОС не может.
Да, конечно. Более того, от наличной аппаратуры на проце зависит. Поэтому не всякая задача грузит разные типы процов одинаково.
   7.0.17.0.1
US Mishka #10.01.2012 23:54  @TheFreeMan#10.01.2012 23:47
+
-
edit
 

Mishka

модератор
★★★
TheFreeMan> С точки зрения внутренней логики Intel CPU, hardware threads на одно ядре абсолютно равнозначны.

Кстати, вопрос. А они точно равнозначны? Или там иногда есть случаи, когда первый набор чуть быстрее второго? Я видел разные подобные вещи, иногда, в силу алгоритма или представления таблиц, обращение к первым входам чуть быстрее. Иногда — к последним.

TheFreeMan> Вот что я хотел с самого начала сказать. :-)
Если бы мы все были телепатами... :F
   7.0.17.0.1
1 2 3 4 5 6

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru