Суть вот в чем - наконец-то появился двухядерник. Так вот можем возможно обяснить как ОС работает с каждым ядром, а то что-то в голове не укладывается. То ли второй проц до загрузки ОС исполняет комманду hlt, а потом получает прерывание от первого ведущего процессора. Как натстраиваются таблицы прерываний и регистры IDT. Кот что нибудь знает по этому вопросу, пожалуста поделитесь инфой. PS: только не нужно осылать к мануалам интела, я прекрасно разбираюсь в защищенном режиме и в работе одного ядра. необходимо как-то осознать как крутяться шестеренки в многопроцессорных системах в реальных ОС.
PROFi Найдешь - поделись Я как раз на эту тему копаю всякий APIC, но пока темно. Да и времени не хватает... Вроде бы так и есть. По крайней мере так по манам Intel'а и AMD. Кстати советую полистать мануал AMD который BIOS and Kernel Deveroper's Guide. А кроме мануала Intel'а 24201606 "Multiprocessor Specification" вроде по этой теме ничего и нет А у меня тоже на днях появится :P В связи с этим поставил себе программу-минимум - сочинить нечто вроде учебного примерчика, который бы из-под DOS'а переходил в протектмод, запускал второе ядро, чего-нибудь на обоих делал (ну, например выводил CPUID на экран, чтобы убедиться, что заработало), после чего возвращал бы все взад. Я, грешным делом, пытался нахаляву найти что-то готовое, но увы. Еще хорошо бы потестить на разных процах, но есть только Core2 и Pentium-D, а AMD'шных двухъядерников в доступе нет Блин, зачем только напомнил... Похоже, светит мне изучение Linux'а, а я его боюсь. Но по крайней мере в нем можно хоть что-то найти. Если логика у меня еще не погорела, то копать надо где-то отсюда: http://tracker.linuxbios.org/trac/L...OSv2/src/cpu/amd/dualcore/dualcore.c?rev=2439
kush Спасибо. Но потихоньку и сам разобрался. Только вот полного описания взаимодействия в системе (да еще на русском) не встречал.
PROFi У меня D945. Когда я копался в этом, то самой большой проблемой для меня было "разбудить" AP (второй процессор). А дальше ... зачем какие то полные описания. Используй IPI. Хоть ты и не любишь Intel - овские мануалы, но ничего лучшего не найдешь. В моей системе (может ошибаюсь, нет того винта) оба проца делят одну IDT. Один проц отвечает за функции OS и взаимодействия пользователя с GUI приложения. Второй проц - за математические вычисления. Посылаю на AP IPI с просьбой посчитать что - нибудь сложное. В обработчике IPI AP переходит в облась памяти, не разделяемую с BSP, и считает.
kush А как ты их разделяешь? Неужели по cpuid? А вообще - спасибо большое, похоже, это наконец-то что-то конкретное... по гуглю найти что-то нереально Собственно, это и есть самая большая проблема для меня. Но теперь хоть есть что почитать.
Ustus Если ты нашел что то кроме вышеперечисленного ? Если да, дай ссылку. Мне кажется, на сайте должен быть отдельный раздел, посвященный этой интересной теме. Но вот, судя по кол-ву сообщений, это мало кому интересно. Я бы хотел чтоб люди побольше делились своим удачным/неудачным опытом в этой области. Задавали вопросы. Со временем могу выложить примитивный пример того, что получилось у меня. Но, к сожалению, он не универсален D945 - 2 физических проца Intel. А ведь есть еще Hyperthreading, AMD 2x. К тому же APIC - это не только многопроцессорность, но и многое другое. Мой вопрос: если два процессора (Pentium D 2x3400Mhz и Conroe E6400) будут выполнять одинаковый продолжительный расчет. Причем физические процессоры каждой машины удастся так хорошо распараллелить, что их взаимодействие друг с другом сведется к минимуму. Какой процессор придет к финишу быстрее ? Не знаю, проводились - ли подобные тесты, но лично мне кажется, что Pentium D.
kush Кроме исходников Линуха - особо ничего достойного И то только для AMD. А тут еще работой грузят, некогда особенно ковырятся Не-а, вряд ли... А вообще-то все зависит от того, КАКИЕ расчеты будут вестись. Есть куча тестов, еще со времен тупорылого противостояния NetBurst vs. Athlon, где немало забавных результатов. Но одно точно - если будет векторная арифметика - этот Конро разорвет этого Преслера как Тузик фуфайку, раза в два (ибо так и было задумано). На потоковых целочисленных вычислениях у Преслера есть шанс, но скорее сохранить паритет, чем выиграть. Чтобы названое сравнение было в пользу Преслера нужен о-о-очень специфический код. Впрочем эта тема недаром зовется "вечной", кроме кучи флуда тут сказать что-то невозможно, только конкретные результаты конкретных тестов, а они, собственно, ни о чем не говорят
память то общая ничего не стоит поместить одинаковое значение в IDTR каждого CPU а в чем проблема есть SIPI (Startup IPI) и шаблон адреса перехода 0xVV000 выбираем конкретное значение вектора VV, размещаем по адресу 0xVV000 код, который будут выполянть AP, посылаем широковещательный SIPI через Local APIC BP, указав в сообщении соответствующий вектор VV
Тема немножко опережает время. Производители из кожи вон лезут чтобы обеспечить поддержку многпроцессорности, и ест-но не делятся инфой со всеми. К сожалению, на форуме рассматриваются технологии вчерашнего дня, а мир вокруг нас уже изменился.
rei3er Вот именно здесь у меня и затык. Но для разнообразия порылся в интеловских мануалах и вдруг - о чудо! - натыкаюсь на более-менее вменяемое описание, даже с примером кода. Неужели Интел научился писать документацию? Хотя это у американских интелов вечно бардак в доках, а евреи в этом отношении молодцы. Так что буду ковыряться, хотя если кто на халяву облагодетельствует куском кода - буду благодарен. А то времени вечно не хватает
Пример инициализации второго процессора (как получилось у меня, PentiumD). 1. Надо находиться в режиме с включенной страничной адрессацией (т.е. защищенный/64). У меня 64. 2. Проинициализировать APIC. 2.1 Промэппировать APIC регистры на область памяти strong uncacheable. Их размер - 4кб. mov dword [0x3000 + 64*8 + 0], 0xfee00000 + 10000011b mov dword [0x3000 + 64*8 + 4], 0 0x3000 - адрес моей пэйдж директории. 0xfee00000 - начальный адрес APIC. В результате APIC регистры будут иметь виртуальный адрес 128 мб. 2.2 Разрешить APIC (ч/з IA32_APIC_BASE). У меня при загрузке разрешен. Поэтому ничего не делаю. 3. Инициализация AP. Из MPspec 1.4: послать INIT IPI; задержка 10мсек послать STARTUP IPI; задержка 200 милисек послать STARTUP IPI; задержка 200 милисек Посылка IPI производится путем записи в ICR (0x300 от базы APIC). У меня получилось чуть проще: mov dword [128*1024*1024 + 0x300], 00001100b*256*256 + 00000101b*256 + 0 mov dword [128*1024*1024 + 0x300], 00001100b*256*256 + 00000110b*256 + 0x18 Здесь все предельно упрощено. Не рассматривается топология многопроцессорной системы, так как заранее известно что программа будет запускаться на PentiumD (2 физических ядра). 00001100b*256*256 - обозначает, что прерываение будет отправлено всем процам, исключая отправителя (т.е. единственному AP). 00000101b*256 - INIT IPI 00000110b*256 - STARUP IPI 0x18 - это означает, что AP станет выполнять код, расположенный по адресу 0x18000. Там должен находиться ваш код перевода AP из реального режима в нормальный.
kush Это можно так и писать, или задержка 10 мс все-таки нужна? 0x18000 - это физический? В смысле для реального режима 1800:0000? Он же стартует в реальном, насколько я понимаю?
Ustus У меня вышло и так и так. Просто второй способ проще. Для надежности лучше использовать официальный метод. 0001:8000.
Ustus ошибся. 0x18000 - физ. адр. в реальн. режиме. 1000:8000 = 1800:0000 = 0x18000 (segreg = 0x1000; gpr = 0x8000) или (segreg = 0x1800; gpr = 0x0000) Т.е. ты все правильно перевел. Если тебя интересует, чему будет равен cs, то я не помню. Проще всего, оказавшись там, вывести его на экран.