OSDev

Интересует тория. Кто видел поделитесь.

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

Но вот вопрос. Как раскидывать по этим очередям задачи? Как избежать проблемы того что задача по переменно будет исполняться то на одном то на другом ядре? Это вызывает проблема пересылке данных из одного кэша в другой.

Насколько сильно влияет сигнал lock на работу с данными? Если в ядрах кэш первого уровня данные не пересекаются то lock не действует это известно. Вопрос в другом если данные общие насколько сильно это влияет?

Много процессорные системы тоже интересуют. Но там всё просто.

Так многоядерная система -- это и есть многопроцессорная, просто несколько процессоров выполнены в одной микросхеме.

Как LOCK влияет сейчас, я не знаю. Вроде бы он существует больше для совместимости, чем по реальной необходимости: процессоры сами следят за когерентностью своих кэшей и т.п.; впрочем, утверждать не буду: тема достаточно сложная, надо вникать, а я уж год как АРМами занят, где всё по-другому :)

Что касается планирования, то можно держать и общую очередь, и индивидуальные -- это технические тонкости. Для эффективности же надо указывать для каждого потока набор масок привязки: самая "внешняя" указывает, на каких вообще логических процессорах данный поток имеет право выполняться (обычно на всех, но вдруг по каким-то причинам будет решено ограничить), ну а "внутренние" указывают предпочтительные логические процессоры. Несколько уровней "предпочтительности" объясняется тем, что в многоядерных процессорах кэш последнего уровня общий; кроме того, не следует забывать и про HT. Так, в случае четырёхъядерного процессора Core i7 с HT всего понадобится три маски, в каждой будет 8 битов -- по числу логических процессоров. Если, например, поток изначально выполнялся на логическом процессоре №3 и ему разрешено выполняться на любом процессоре, то эти маски будут иметь значения: "внешняя" -- FF (можно выполнять поток на любом процессоре); "средняя" -- FF (если поток невозможно запустить на предпочтительном логическом процессоре, то следует запускать его на любом свободном); "внутренняя" -- 0C (поток желательно запускать на логическом процессоре №2 или №3, поскольку физически это одно и то же ядро с общими кэшами 1-го и 2-го уровней).

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

В общем, примерно так :)

В том то и дело что не просто. В многоядерной системе L2 кэш у них общий. А L1 принадлежит каждый своему ядру.
А под много процессорной системой. Я понимаю кластер. У каждого процессора своя RAM свой HDD.


В том то и вопрос как оценить затраты на перекидывания? В мобильной системе лучше вообще не перекидывать.
В двух ядерной системе более или менее понятно.
А если ядер 16 штук(ближайшее будущее). То вопрос как их раскидывать. Толи все на одну задачу толи один на антивирус 12 на основную задачу 2 на другии задачу и 1 спит. Толи еще как.

А да еще раз замечу в вопросе я говорил о задачах, а не о потоках.

Кэш третьего уровня я вообще не рассматриваю. Он как обычная память.

Может, после переноса потока на новое ядро делать это ядро "родным"? (Это к предыдущему посту.)

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

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

lock приводит к синхронизации кэшируемого блока, но не всего кэша. При хорошем распределении данных, межблочное влияние минимально.
Главное из топологии процессора выяснить размер кэшируемого блока, и размещать не больше одной переменной на блок. Для Intel Pentium это обычно 64 или 128 байт.

Спасибо но в вопросе это утверждение я уже написал. Вопрос звучал когда пересылать, а когда нет? Жесткая привязка тоже плоха свободные процессоры начнут простаивать.


Это я знаю, вопрос в том какие издержки от lock или как их померить?

Можно ввести временной порог загруженности, тоесть накапливать статистику. Если по прошествии некоторого числа квантов загруженность ядра остаётся линейной, то можно начинать процесс перераспрелеления. Таким образом, перераспределение будет происходить не постоянно и хаотично, а только через каждые 100 квантов или м.сек.

По идее, издержки lock равны времени чтения данных из кэша памяти 2 уровня. Вся завязка именно на кэше. И по идее, задержки должны быть только при колллизиях, когда данные изменились.
Можно конечно померять счётчиком tsc, надо только запустить параллельную задачу, которая будет изменять данные в бесконечном цикле. Мерять надо на конкретной системе, а сторонние результаты будут очень разнообразными.

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



А что понимать под задачей? О терминах договариваться сначала надо...



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

В i5-i7 (нету проверить неначем)
Кэш 3 уровня 26-31
В Core2Due без кэш 3 уровня
RAM 14+5.5+RAM те 21-24
И что быстрее?

Что значит индивидуальные? Не ну доступ к другим кэшам L2 L1 идет через L3 и это понятно.
На самом дели они не такие индивидуальные так как интел использует технологию "Умный Кэш" (смарт кэш). И както более хитро организует процесс. Но в это в даваться не буду. Вот только не понял зачем им кэш второго уровня? Такое впечатления что ерунду нагородили. Тем более скорость современной памяти 1.6-2 гигагерца что почти сравнялась с частотой процессора.


Процесс и потоки подразумевают деление на кванты. А задачи я свойственен понимать нечто без кванта времени. Скажем так, меньше потока. В общем есть понятие пула потоков. Так вот под задачу выбираются из пула свободный поток. Для удобства можем ввести понятие микрозадачи и макрозадачи.
Микразадача не делимая. А макразадача состаит из микразадачь.
Из предыдущих сообщений надеюсь было понятно что выбирать из пул потоков не интересно. Более лучше назначать задачи(микрозадачи) потокам.

1 уровень. Уровень на котором ОС распределение макрозадачи по ядрам это планирование процессов.
2 уровень. Уровень на котором Процесс распределяет ядра по потокам.
3 уровень. Уровень на котором микрозадачи распределяются по потокам.

Структура пока не строгая. Возможно уровни сольются.

А да перераспределять через 100 квантов без с мысленно. Я за микросекунды борюсь.