SMP. Некоторые подробности.

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

SMP. Некоторые подробности.

Anton Maksimenkov-2
Если многоуважаемое сообщество позволит... я хотел бы скомпоновать и
вынести SMP в отдельный тред (и для архива в том числе).
Надеюсь, это будет интересно и будущим читателям, когда поиск по
архиву заработает ;)

Для начала вот это - http://crypt.org.ru/~mkb/pub/talks/openkyiv2008.pdf
Уж простят меня остальные именитые <<отцы>>, но такие доки сильно
помогают понять суть, а потому рекомендуется прочитать.

Не напрямую SMP, но для затравки оставляю:
> известный факт что большинство тормозов юзерленда из-за универсального
> интерфейса сокетов.  весь (часть) TCP/IP стек(а) можно вынести в юзерланд,
> выкинув весь software intrrupt процессинг.  в тун запихнуть можно тем же
> bpf'ом.
> опять же pf это фактически до -100Mbit/s.  в частности из-за "scrub in".


Что такое software intrrupt?

> Когда приходит прерывание от сетевой карты (hardware interrupt), драйвер
> вынимает из нее кадр. Но обработать его, то есть пропарсить все
> заголовки, выделить tcp сегмент и т.д. он не может, как как это дело
> долгое, возможно связанное с выделением памяти, и поэтому не может
> происходить в контексте аппаратного прерывания.
>
> Вместо этого драйвер генерирует так называемое "программное" прерывание
> (software interrupt), например ставит некий флажок в ядре, вы завершает
> обработку аппаратного прерывания. Программное прерывание затем будет
> обработано например по выходу из какого-нибудь системного вызова или при
> переключении процессов. И уже обработчик этого прерывания будет делать
> обработку пакета.
>
> Проблема при таком подходе - это неконтролируемые задержки в обработке
> входящих пакетов и лишняя трата времени.


SMP... Кстати, что там слышно "в кругах", конкурирующая SMPng оно к
опёнку никак не это...?

> SMPng это из фри?  Никак не помогает.
> А так надо много чего чинить, даже если хочется чтобы базовые spl'и
> превратились в мутексы.


Почему в текущем виде ни в опене ни, как я понимаю, во фре невозможно
какую-то часть кернела крутить на другом(их) ядре процессора.

> Чтобы запустился ядерный код, нужно либо прерывание, либо исключение. В
> обоих случаях перед входом в обработчик ядро пытается захватить
> глобальный лок. Если он уже захвачен (работает обработчик на другом
> процессоре), данный процессор начинает греть царствие небесное, крутясь в
> спинлоке. Когда обработка прерывания или исключения на другом процессоре
> закончилась, наш процессор начинает исполнять ядерный код. Таким образом
> в данный момент времени только один процессор может исполнять код ядра.
> Все остальные могут исполнять или пользовательские инструкции, или
> висеть в спинлоках, ожидая свою очередь войти в ядро.


Моё понимание SMP в опене остановилось на том, что кернел садится на
первое ядро проца...

> ну это частично неправльное понимание.  кернел исполняется на всех
> процессах в S(!)MP системе (на то она и симметричная).  бутится кернель
> на бутовом проце, дальше, обнаружив (из MPBIOS таблиц или из ACPI),
> что присутствуют еще процы он их "запускает", инсталлируя для каждого
> по MP трамполину и посылая серию IPI (то бишь InterProcessor Interrupt).
> каждый Application CPU начинает исполнение кернела грубо говоря с
> функции main.
>
> для чего всё то. а для того чтобы процесс, исполняющийся на цпу1 и
> захотевший сделать сисколл (read например) залез в кернель на том
> же цпу1.
>
> теперь про локинг.  на UP машинах весь локинг реализуется с помощью
> маскирования прерываний (SPL, Set Interrupt Priority), таким образом
> сделав splnet() мы застраховали себя от возможности быть прерванным
> любым другим прерыванием с уровнем IPL_NET и ниже (см. spl(9)).
> на MP машинах у каждого цпу есть своя маска прерываний и посему
> такой метод уже не достаточен, поэтому в MP системах нужны два типа
> блокировок: CPU exclusion lock и process exclusion lock.  первый
> тип локов ограничивает конкурентный доступ к ресурсу между несколькими
> CPU и в OpenBSD реализован как spinning mutex(9).  Разграничение
> между доступом к ресурсу, раздиляемому только процессами реализовано
> спящим (при желании) локом rwlock(9), поскольку спать можно только
> в контексте процесса.
>
> про прерывания.  прерывания в MP системах на i386 и amd64 приходят
> на устройство I/O APIC, реализованном в системном чипсете, тогда как
> маска IRQ находится непосредственно в CPU (LAPIC, Local Advanced
> Programmable Interrupt Controller).  все цпя сидят на одной шине
> с I/O APICами (их может быть несколько) и прерываются в зависимости
> от своей маски.  в OpenBSD прерывания обрабатываются только на
> boot процессоре.
>
> биглок (он же kernel_lock) разграничивает доступ к ядру для всех
> процессов и прерваний, происходящих в системе.  он берется
> автоматически при каждом входе процесса в ядро (сисколл, трап) и
> при каждом прерывании, тем самым предотвращая все возможные гонки
> за ресурсы ядра.  отдать его можно явно вызвав KERNEL_PROC_UNLOCK
> в контексте процесса.
>
> если процесс зашел в кернел по сисколу, взял биглок и работает
> с уровнем IPL_NONE, ничто не мешает прийти прерыванию, прервать
> процесс, поднять IPL до заданного уровня, рекурсивно взять
> kernel_lock выполнится, отдать biglock, вернуть управление
> процессу.
>
> при контексном переключении биглок отдается, процесс помечается
> как P_BIGLOCK и при следующем переключении на него, биглок будет
> возвращен.
>
> существует также еще один рекурсивный лок -- sched_lock,
> предохраняющий данные скедулера, всегда используется с
> уровнем IPL_SCHED (соотв. IPL_HIGH).
>
> при работе с локами важно соблюдать порядок взятия и отдачи
> локов:
>
> - правильно:
>
>        lock_enter(1);
>        lock_leave(1);
>        lock_enter(2);
>        lock_leave(2);
>
> - правильно:
>
>        lock_enter(1);
>        lock_enter(2);
>        lock_leave(2);
>        lock_leave(1);
>
> - НЕправильно:
>
>        lock_enter(1);
>        lock_enter(2);
>        lock_leave(1);
>        lock_leave(2);

--
engineer
Reply | Threaded
Open this post in threaded view
|

Re: SMP. Некоторые подробности.

Anton Maksimenkov-2
1)
>> бутится кернель
>> на бутовом проце, дальше, обнаружив (из MPBIOS таблиц или из ACPI),
>> что присутствуют еще процы он их "запускает", инсталлируя для каждого
>> по MP трамполину и посылая серию IPI (то бишь InterProcessor Interrupt).
>> каждый Application CPU начинает исполнение кернела грубо говоря с
>> функции main.

Что есть "MP трамполина"?

 Кусок текста
...The trampoline code calculates the desired stack base from the code segment
(since the code segment on startup is the bottom of the stack), enters 32bit
mode and jumps to the kernel entry assembler...
не дал понимания.
 Посмотрел в код, там ассемблер. Из каментов понял что это вроде как
однократный код, исполняемый для запуска процессора. Инициализирует
его и вводит в исполнение кернела. Или он потом ещё как-то участвует?

2)
>> для чего всё то. а для того чтобы процесс, исполняющийся на цпу1 и
>> захотевший сделать сисколл (read например) залез в кернель на том
>> же цпу1.

Поясни почему 1) приводит к 2)?


>>  в OpenBSD прерывания обрабатываются только на
>> boot процессоре.

>> биглок (он же kernel_lock) разграничивает доступ к ядру для всех
>> процессов и прерваний, происходящих в системе.  он берется
>> автоматически при каждом входе процесса в ядро (сисколл, трап) и
>> при каждом прерывании, тем самым предотвращая все возможные гонки
>> за ресурсы ядра.  отдать его можно явно вызвав KERNEL_PROC_UNLOCK
>> в контексте процесса.

Биглок - он же CPU exclusion lock?

Так, если все прерывания от I/O и таймера (может ещё что, но вобщем НЕ
сисколлы, и НЕ software interrupt'ы, да?) маскированы только на boot
processor, то зачем им биглок? Ведь другие процессоры, как я понимаю,
в своей маске никаких "железных" прерываний не имеют и не
обрабатывают?
Ведь обработчик "железного" прерывания, как я понимаю, структуры ядра
не изменяет (могущие повлечь гонки с сисколлами и софтварными
интерраптами), а в основном "готовит почву" и ставит флаг вызова
софтварного интеррапта.
А если и изменяет (так, что могут быть гонки), тогда вобщем-то
желательно ограничить те куски, где возможны гонки, более мягкими
блокировками.
Я правильно понимаю, что это и есть и будет основная работа по
переходу от биглока к fine grained блокировкам?

Далее. Для сисколлов и software interrupt'ов понятно, что биглок
получается нужен, ибо они исполняется как раз не только на boot
процессоре, а на всех. Ну понятно, что и тут переход от биглока к
более тонким блокировкам в будущем необходим.
Мне непонятно вот что. Вот процесс, исполняющийся на 3-м процессоре,
вызывает сисколл. Генерируется software interrupt. Все процессоры
прерываются, входят в обработчик софтварного прерывания и пытаются
захватить биглок.
Как так получится, что его захватит (и будет исполнять сисколл) именно
3-й процессор, а не любой другой?

Дальше, вот захватил 3-ий процессор биглок. Остальные что?
--
engineer
Reply | Threaded
Open this post in threaded view
|

Re: SMP. Некоторые подробности.

Anton Maksimenkov-2
Сам спросил, сам и отвечаю :-))

> Так, если все прерывания от I/O и таймера (может ещё что, но вобщем НЕ
> сисколлы, и НЕ software interrupt'ы, да?) маскированы только на boot
> processor, то зачем им биглок? Ведь другие процессоры, как я понимаю,
> в своей маске никаких "железных" прерываний не имеют и не
> обрабатывают?

 Затем, что во время обработки одного прерывания могут прийти ещё
прерывания и тоже начать писать что-то в структуры. Поэтому и
используются уровни spl(9), которые соответственно блочат остальные
такие же и менее приоритетные прерывания, пока выполняется текущий
обработчик.

ЗЫЖ теперь вкурил что имел ввиду mkb@ про "если хочется чтобы базовые
spl'и превратились в мутексы".
--
engineer
Reply | Threaded
Open this post in threaded view
|

Re: SMP. Некоторые по

Mike Belopuhov
In reply to this post by Anton Maksimenkov-2
On Fri, Feb 13, 2009 at 11:32 +0500, engineer wrote:

> 1)
> >> бутится кернель
> >> на бутовом проце, дальше, обнаружив (из MPBIOS таблиц или из ACPI),
> >> что присутствуют еще процы он их "запускает", инсталлируя для каждого
> >> по MP трамполину и посылая серию IPI (то бишь InterProcessor Interrupt).
> >> каждый Application CPU начинает исполнение кернела грубо говоря с
> >> функции main.
>
> Что есть "MP трамполина"?
>
>  Кусок текста
> ...The trampoline code calculates the desired stack base from the code segment
> (since the code segment on startup is the bottom of the stack), enters 32bit
> mode and jumps to the kernel entry assembler...
> не дал понимания.
>  Посмотрел в код, там ассемблер. Из каментов понял что это вроде как
> однократный код, исполняемый для запуска процессора. Инициализирует
> его и вводит в исполнение кернела. Или он потом ещё как-то участвует?
>

никак, служит как раз для того, что ты написал.


> 2)
> >> для чего всё то. а для того чтобы процесс, исполняющийся на цпу1 и
> >> захотевший сделать сисколл (read например) залез в кернель на том
> >> же цпу1.
>
> Поясни почему 1) приводит к 2)?
>

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

>
> >>  в OpenBSD прерывания обрабатываются только на
> >> boot процессоре.
>
> >> биглок (он же kernel_lock) разграничивает доступ к ядру для всех
> >> процессов и прерваний, происходящих в системе.  он берется
> >> автоматически при каждом входе процесса в ядро (сисколл, трап) и
> >> при каждом прерывании, тем самым предотвращая все возможные гонки
> >> за ресурсы ядра.  отдать его можно явно вызвав KERNEL_PROC_UNLOCK
> >> в контексте процесса.
>
> Биглок - он же CPU exclusion lock?
>
> Так, если все прерывания от I/O и таймера (может ещё что, но вобщем НЕ
> сисколлы, и НЕ software interrupt'ы, да?) маскированы только на boot
> processor, то зачем им биглок? Ведь другие процессоры, как я понимаю,
> в своей маске никаких "железных" прерываний не имеют и не
> обрабатывают?

ну так а что тогда мешает зайти процессу на другом цпу в кернель?
вообще дядя tedu грозился сделать mpsafe interrupts и даже чего-то
коммитил, но, видать обкурившись.  ошибок уйму наделал и убрал всё
взад.

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

например он достаёт новый mbuf из mbpool.

> А если и изменяет (так, что могут быть гонки), тогда вобщем-то
> желательно ограничить те куски, где возможны гонки, более мягкими
> блокировками.

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

> Я правильно понимаю, что это и есть и будет основная работа по
> переходу от биглока к fine grained блокировкам?
>

ну более или менее.  ещё бы прибить kmem_map и вот товарищи всё
недовольны рекурсивными kernel_ и sched_ локами, но я пока ещё
не допёр в чем с ними проблема.

> Далее. Для сисколлов и software interrupt'ов понятно, что биглок
> получается нужен, ибо они исполняется как раз не только на boot
> процессоре, а на всех.

сейчас все softintr'ы исполняются также на boot процессоре.

> Ну понятно, что и тут переход от биглока к
> более тонким блокировкам в будущем необходим.

softintr'ы должно быть не сильно сложно попробовать сделать fine grained.

> Мне непонятно вот что. Вот процесс, исполняющийся на 3-м процессоре,
> вызывает сисколл. Генерируется software interrupt. Все процессоры
> прерываются, входят в обработчик софтварного прерывания и пытаются
> захватить биглок.

почему все процессоры?  только тот что взялся его обрабатывать (в опене
опять же boot cpu).

> Как так получится, что его захватит (и будет исполнять сисколл) именно
> 3-й процессор, а не любой другой?
>
> Дальше, вот захватил 3-ий процессор биглок. Остальные что?
> --
> engineer


Reply | Threaded
Open this post in threaded view
|

Re: SMP. Некоторые подробности.

Anton Maksimenkov-2
In reply to this post by Anton Maksimenkov-2
> оно не приводит, это просто факты.  2) потому что быстрее в свой цпу
> залезть, чем всем трешить кэши у других.
...
> сейчас все softintr'ы исполняются также на boot процессоре.

Стал подозревать - доставка software interrupt'ов через APIC
программируется? Что-то вроде того, какому процу доставлять
сгенерённые на "моём" проце software interrupt'ы (например самому
себе, или кому-то другому). И сейчас на каждом проце APIC
программируется доставлять software interrupt'ы на boot processor.

И ещё. Если "...быстрее в свой цпу залезть, чем всем трешить кэши у
других...", и тут же "...сейчас все softintr'ы исполняются также на
boot процессоре...", значит сейчас как раз "трешатся кэши" при каждом
софтварном прерывании? Точнее, кэш трешится видимо на boot
processor'е.

Вдобавок я потерял мысль, что происходит на других (не boot) процах,
когда они вызывают сисколл? Что между ними и boot процом после этого
происходит, на всех этапах вплоть до завершения сисколла?
(Насочинял много, но решил здесь не писать, чтобы не засорять и не
заставлять всех читать эту муть, к тому же скорее всего ошибочную).

>> Ведь другие процессоры, как я понимаю,
>> в своей маске никаких "железных" прерываний не имеют и не
>> обрабатывают?
>
> ну так а что тогда мешает зайти процессу на другом цпу в кернель?
> вообще дядя tedu грозился сделать mpsafe interrupts и даже чего-то
> коммитил, но, видать обкурившись.  ошибок уйму наделал и убрал всё
> взад.
Дык вот тока теперь я понял чтО мешает - они (software interrupts)
маскированы только на boot processor'е (или APIC'ами заворачиваются со
всех других на него, я ещё не уверен, что правильно понял). И
получается, что в кернель заходит только boot проц, а остальные вообще
не заходят (здесь я потерял мысль про сисколлы :-))...

А вообще, не помнишь поподробнее что за коммит, ссылочку бы какую или
по каким словам искать. Хотелось бы посмотреть что там за идеи. Я
сегодня поискал-поискал, чо-т не нашёл чего-то напоминающего это, тока
какое-то старьё немного похожее.
--
engineer
Reply | Threaded
Open this post in threaded view
|

Re: SMP. Некоторые по

Mike Belopuhov
On Mon, Feb 16, 2009 at 22:26 +0300, engineer wrote:
> > оно не приводит, это просто факты.  2) потому что быстрее в свой цпу
> > залезть, чем всем трешить кэши у других.
> ...
> > сейчас все softintr'ы исполняются также на boot процессоре.
>
> Стал подозревать - доставка software interrupt'ов через APIC
> программируется?

я начал было писать объяснение, но подумал что пользы никакой не будет.
посмотри сам, начав например в ether_input().  намекну что ведет оно
например к:

        switch (etype) {
#ifdef INET
        case ETHERTYPE_IP:
                schednetisr(NETISR_IP);
                inq = &ipintrq;
                break;
        ...

        IF_INPUT_ENQUEUE(inq, m);

        splx(x);

то есть данные попадают в ipintrq и скедулится NETISR_IP.
скажу еще что на этот splx надо внимательно посмотреть.

> Что-то вроде того, какому процу доставлять
> сгенерённые на "моём" проце software interrupt'ы (например самому
> себе, или кому-то другому). И сейчас на каждом проце APIC
> программируется доставлять software interrupt'ы на boot processor.
>
> И ещё. Если "...быстрее в свой цпу залезть, чем всем трешить кэши у
> других...", и тут же "...сейчас все softintr'ы исполняются также на
> boot процессоре...", значит сейчас как раз "трешатся кэши" при каждом
> софтварном прерывании? Точнее, кэш трешится видимо на boot
> processor'е.
>

ну так надо делать чтобы эту очередь отложеных задачь обрабатывать
на разных cpu.
 
> Вдобавок я потерял мысль, что происходит на других (не boot) процах,
> когда они вызывают сисколл? Что между ними и boot процом после этого
> происходит, на всех этапах вплоть до завершения сисколла?
> (Насочинял много, но решил здесь не писать, чтобы не засорять и не
> заставлять всех читать эту муть, к тому же скорее всего ошибочную).
>

так ничего не происходит, биглок то у кого-то одного только взят.

> >> Ведь другие процессоры, как я понимаю,
> >> в своей маске никаких "железных" прерываний не имеют и не
> >> обрабатывают?
> >
> > ну так а что тогда мешает зайти процессу на другом цпу в кернель?
> > вообще дядя tedu грозился сделать mpsafe interrupts и даже чего-то
> > коммитил, но, видать обкурившись.  ошибок уйму наделал и убрал всё
> > взад.
> Дык вот тока теперь я понял чтО мешает - они (software interrupts)
> маскированы только на boot processor'е (или APIC'ами заворачиваются со
> всех других на него, я ещё не уверен, что правильно понял). И
> получается, что в кернель заходит только boot проц, а остальные вообще
> не заходят (здесь я потерял мысль про сисколлы :-))...
>

сисколы заходят.

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

http://marc.info/?l=openbsd-cvs&m=122853808223161&w=2
пытался исправить что-то:
http://marc.info/?l=openbsd-cvs&m=122854023224983&w=2
http://marc.info/?l=openbsd-cvs&m=122854021124954&w=2
http://marc.info/?l=openbsd-cvs&m=122858606308597&w=2
откатил:
http://marc.info/?l=openbsd-cvs&m=122859389317707&w=2

> --
> engineer


Reply | Threaded
Open this post in threaded view
|

Re: SMP. Некоторые по

Anton Maksimenkov-2
>> > сейчас все softintr'ы исполняются также на boot процессоре.
>> Стал подозревать - доставка software interrupt'ов через APIC
>> программируется?
>
> посмотри сам, начав например в ether_input().  намекну что ведет оно
> например к:
>
>        switch (etype) {
> #ifdef INET
>        case ETHERTYPE_IP:
>                schednetisr(NETISR_IP);
>                inq = &ipintrq;
>                break;
>        ...
>
>        IF_INPUT_ENQUEUE(inq, m);
>
>        splx(x);
>
> то есть данные попадают в ipintrq и скедулится NETISR_IP.
> скажу еще что на этот splx надо внимательно посмотреть.

М. Пораскапывал, понял, что schednetisr установит бит а-ля "а ещё
обработайте нетворк" в int переменной, которая показывает своими
битами какие "типы" софтпрерываний произошли. Причём через
atomic_setbits_int(...), которое видимо не даст попортить переменную,
если в этот момент нагрянет более приоритетное прерывание (которое
тоже может эту переменную потрогать).
Потом вызывается softintr(int sir) в которой просто одна строчка на
asm'е, в которой участвует некая инфа от проца (curcpu).
Я уже не понял что она делает. Но там есть буквы 'ir', фантазирую что
это как раз выдаёт сигнал software interrupt :-))).

> скажу еще что на этот splx надо внимательно посмотреть.
Посмотрел. Понял, что приведённый кусок (ether_input) работает с
защитой на уровне splnet(). Который выше софтового прерывания. Значит
schednetisr(NETISR_IP), вызвав софтовое прерывание, сама не
прерывается (ну то есть выполняя её проц не перекинется в
софтпрерывание), а завершается и выходит, дело продолжается дальше в
ether_input.
Под конец вызывается splx(s), которая возвращает уровень защиты на
предыдущий. Пока не знаю какой он был или мог быть, но видимо после
этой splx(s) возникает шанс выполниться (обработаться) зашедуленному
софтовому прерыванию. Которое и будет обрабатывать цепочку ipintrq (с
уже засунутым в неё m, то есть без гонок).
Это то, что следовало понять или есть ещё что-то?

Вообще, где место в коде, с которого начинается выполнение софтового интеррапта?


Вернусь ещё сюда:
>> Вдобавок я потерял мысль, что происходит на других (не boot) процах,
>> когда они вызывают сисколл? Что между ними и boot процом после этого
>> происходит, на всех этапах вплоть до завершения сисколла?
> так ничего не происходит, биглок то у кого-то одного только взят.
>> получается, что в кернель заходит только boot проц, а остальные вообще
>> не заходят (здесь я потерял мысль про сисколлы :-))...
> сисколы заходят.

Я хотел понять последовательность "кто кого за что дёргает". То есть,
вот ушёл НЕboot проц в сисколл. Получает софтинтеррапт. И при этом
ранее говорили, что
>> > сейчас все softintr'ы исполняются также на boot процессоре.

Немного читал "Pentium(R) Processor Family Developer's Manual", много
думал. :-))
Поэтому дальше я фантазирую себе так.
.
1) Тот, НЕboot процессор теперь ВХОДИТ в обработчик софтинтеррапта
(работая теперь в режиме кернела), хватает биглок. Помечает в
int-переменной (типа того же что в schednetisr было) какой именно
софтинтеррапт нужно "обработать". Затем он (НЕboot проц) отправляет
другое софтпрерывание конкретно boot процессору. А сам при этом хз чо
дальше делает... Просто непрерывно крутится в цикле ожидания чего-то?
Хватает биглок, проверяет не исполнилась ли нужная обработка, если нет
- снова отпускает биглок и цикл повторяется, если да то переходит к
(3)?
Или может исполнять другой неблокированный юзерский процесс (ну... тут
тогда ещё вопросы будут)?
И ещё. Если он при входе хватал биглок, то теперь же должен его
отпустить, чтобы дать остальным процам (и конкретно boot процу)
обрабатывать прерывания и сисколлы (входя туда, как тут говорили,
сразу хватается биглок, или проц блокируется в ожидании его
получения).
.
2) Теперь boot проц (если не был занят более высокоуровневыми
прерываниями) прерывается софтинтерраптом, _ВХОДИТ_ в обработчик
софтинтеррапта, хватает биглок, и смотрит ту int-переменную. И
выполняет те обработчики, какие биты в ней установлены. После того как
boot проц заканчивает обработку этого софтварного прерывания, он
должен, видимо, отправить софтинтеррапт тому самому, вызвавшему сискол
НЕboot процу. Затем сам boot проц отпускает биглок, _ВЫХОДИТ_ из
софтпрерывания и продолжает что делал.
.
3) Теперь НЕboot проц снова ВХОДИТ в софтпрерывание (или не выходил из
него? я не понял), хватает биглок, видит некие сведения о том, что его
сисколл выполнен, отпускает биглок, ВЫХОДИТ из софтпрерывания, и
возвращается из сисколла в юзерском процессе.
Схема в целом такая или нет?

Тока не пойму что там с биглоком в первом сисколле, когда НЕboot проц
в него вошёл, а работать должен boot проц. Видимо я где-то неправильно
нафантазировал.

--
engineer
Reply | Threaded
Open this post in threaded view
|

Re: SMP. Некоторые по

Anton Maksimenkov-2
> Вообще, где место в коде, с которого начинается выполнение софтового интеррапта?

Уже нашлось, в процессе беседы с Alex V Breger
> вот выполнение софт. прерываний в опенке
> http://fxr.watson.org/fxr/source/arch/i386/i386/softintr.c?v=OPENBSD;im=excerpts#L77
> Осталось понять, откуда вызывается функция  softintr_dispatch. Я с
> наскоку не смог найти. Возможно, в дереве не все исходники, и часть их

А softintr_dispatch() в arch/i386/i386/apicvec.s вызывается из asm кода.

ЗЫЖ. Остальные вопросы актуальны ;)
--
engineer
Reply | Threaded
Open this post in threaded view
|

Re: SMP. Некоторые по

Anton Maksimenkov-2
>> Вообще, где место в коде, с которого начинается выполнение софтового интеррапта?
о боже, какой же я тормоз.
софтовый интеррапт никакой не интеррапт в смысле железного сигнала. а
дело просто в том, что после любого реально поступившего железного
интеррапта, под конец его выполнения просто смотрится не поставил ли
кто-то флажок-бит в переменной "софтовое прерывание".

а я всё это дело путал в голове и с 0х80 и с "самопрерыванием" и
вообще такую кашу намешал...
--
engineer
Reply | Threaded
Open this post in threaded view
|

Re: SMP. Некоторые подробности.

Anton Maksimenkov-2
In reply to this post by Anton Maksimenkov-2
Для тех кто следит за тредом.

> Вернусь ещё сюда:
>>> Вдобавок я потерял мысль, что происходит на других (не boot) процах,
>>> когда они вызывают сисколл? Что между ними и boot процом после этого
>>> происходит, на всех этапах вплоть до завершения сисколла?
>> так ничего не происходит, биглок то у кого-то одного только взят.
>>> получается, что в кернель заходит только boot проц, а остальные вообще
>>> не заходят (здесь я потерял мысль про сисколлы :-))...
>> сисколы заходят.
>
> Я хотел понять последовательность "кто кого за что дёргает". То есть,
> вот ушёл НЕboot проц в сисколл. Получает софтинтеррапт. И при этом
> ранее говорили, что
>>> > сейчас все softintr'ы исполняются также на boot процессоре.

Всё это бредятина моя, выкидываем её. А дело вот как обстоит.

Когда процесс входит в сисколл, то никакой software interrupt не
"вызывается", а вызывается asm инструкция 0x80 - так называемый
software trap (который иногда называют software interrupt, что сбивает
с толку).
Она переводит проц в контекст ядра (а не прерывания).

Теперь исполняется код сисколла, в контексте ядра. При этом, если для
сисколла не установлен флаг SY_NOLOCK, то перед его вызовом будет
сначала захватываться биглок, потом вызываться обработчик сисколла,
выполняется и завершается, потом биглок отпускается.
В коде trap.c (для каждого типа машины свой, но тем не менее) это вот:
if (lock)
    KERNEL_PROC_LOCK(p);
    orig_error = error = (*callp->sy_call)(p, args, rval);
if (lock)
    KERNEL_PROC_UNLOCK(p);
Так вот, если надо будет что-то сделать в контексте прерывания
(например запихать таки пакет в сетевую карту, да), этот сисколл может
"зашедулить отложенный интеррапт" (software interrupt) путём установки
бита в int-переменной. Но и только.

Дальше. В опенбсд все прерывания "направлены" (настроены в APIC) на
boot процессор.  Соответственно только он и прерывается.
Прерывания тоже хватают биглок, чтобы не было гонок при изменении
неких структур (тех же mbuf'ов например), которые могут трогать и
сисколлы (которые работают на других процах).
.
Здесь нужно отвлечься на то, что прерывания имеют разные уровни.
Прерывания более высокого уровня могут прервать обрабатывающееся
прерывание более низкого уровня. То есть рекурсивно вызваться (прервав
выполнение более низкоуровневого), отработать, выйти, после этого проц
вернётся к доисполнению "предыдущего прерванного прерывания".
.
Есть spl(9)-функции, которые позволяют блокировать прерывания
заданного или более низкого уровня (то есть не дать им прервать
выполнение кода, который в spl-обёртке), чтобы оградить некие куски от
гонок с прерываниями. Сисколл работает на "самом низком spl уровне",
то есть совсем без уровня, IPL_NONE.
.
Итак любое железное прерывание может прервать посреди дороги
выполняющийся сисколл, поднять spl уровень и после этого ОТОБРАТЬ
биглок у сисколла. При этом процесс (сисколл) блокируется и помечается
как P_BIGLOCK. Когда прерывание закончится и выйдет, биглок будет
возвращен этому процессу и он оживёт.
Таким образом, сейчас в параллель могут работать:

1) - юзерспейс (он независимо работает на каждом проце, и тока на boot
проце он может быть прерван прерыванием),

2) - сисколл без SY_NOLOCK - на любом проце (получил биглок и работает,),
    - либо прерывание на boot проце (получило или отобрало биглок и работает).

3) - сисколлЫ с SY_NOLOCK (но внутри него может быть mutex или rwlock
- тут уже думайте сами) - на любом проце,
    - на boot проце такой сисколл, понятно, тоже может быть прерван
прерыванием, но на других процах сисколлы с SY_NOLOCK будут работать.
Ну тут широкое поле, логически подумайте (например про сисколл
блокируемый и неблокируемый).

Теперь собственно к software interrapt'у.
Под конец обработки каждого прерывания (ещё до выхода), в spllower(),
проверяется "а не зашедулил ли кто отложенный интеррапт?". И если таки
зашедулил, то запускается соответствующий обработчик. Он работает всё
ещё в контексте прерывания, собственно для того и шедулили. Во время
работы он может (тут уже это я так понимаю, код ещё не смотрел)
поднять свой spl уровень, когда делает что-то, что может вызвать гонки
(например, обращается к тем же mbuf'ам, когда пихает таки пакет в
сетевую карту). А могут и его прервать более высокоуровневые
интеррапты, у которых spl будет выше, чем он себе взял.
Когда он наконец отрабатывает, тогда уже происходит выход из
прерывания. Будет освобождён биглок (или отдан процессору и процессу у
которого его отобрали, который помечен P_BIGLOCK). Теперь boot проц
переключается из контекста прерывания в контекст процесса и продолжает
выполнять то на чём он там закончил.


Большой спасиб Михаилу Белопухову, который помог всё разжевать и
понять, а также всем остальным за наводки.
--
engineer
Reply | Threaded
Open this post in threaded view
|

Re: SMP. Некоторые подробности.

Mike Belopuhov
On Tue, Feb 17, 2009 at 22:22 +0300, engineer wrote:
> Для тех кто следит за тредом.
>

а шо есть такие? :-)

> > Вернусь ещё сюда:
> >>> Вдобавок я потерял мысль, что происходит на других (не boot) процах,
> >>> когда они вызывают сисколл? Что между ними и boot процом после этого
> >>> происходит, на всех этапах вплоть до завершения сисколла?
> >> так ничего не происходит, биглок то у кого-то одного только взят.
> >>> получается, что в кернель заходит только boot проц, а остальные вообще
> >>> не заходят (здесь я потерял мысль про сисколлы :-))...
> >> сисколы заходят.
> >
> > Я хотел понять последовательность "кто кого за что дёргает". То есть,
> > вот ушёл НЕboot проц в сисколл. Получает софтинтеррапт. И при этом
> > ранее говорили, что
> >>> > сейчас все softintr'ы исполняются также на boot процессоре.
>
> Всё это бредятина моя, выкидываем её. А дело вот как обстоит.
>
> Когда процесс входит в сисколл, то никакой software interrupt не
> "вызывается", а вызывается asm инструкция 0x80 - так называемый
> software trap (который иногда называют software interrupt, что сбивает
> с толку).
> Она переводит проц в контекст ядра (а не прерывания).
>
> Теперь исполняется код сисколла, в контексте ядра. При этом, если для
> сисколла не установлен флаг SY_NOLOCK, то перед его вызовом будет
> сначала захватываться биглок, потом вызываться обработчик сисколла,
> выполняется и завершается, потом биглок отпускается.
> В коде trap.c (для каждого типа машины свой, но тем не менее) это вот:
> if (lock)
>     KERNEL_PROC_LOCK(p);
>     orig_error = error = (*callp->sy_call)(p, args, rval);
> if (lock)
>     KERNEL_PROC_UNLOCK(p);
> Так вот, если надо будет что-то сделать в контексте прерывания
> (например запихать таки пакет в сетевую карту, да), этот сисколл может
> "зашедулить отложенный интеррапт" (software interrupt) путём установки
> бита в int-переменной. Но и только.
>
> Дальше. В опенбсд все прерывания "направлены" (настроены в APIC) на

более конкретно - в LAPIC.

> boot процессор.  Соответственно только он и прерывается.
> Прерывания тоже хватают биглок, чтобы не было гонок при изменении
> неких структур (тех же mbuf'ов например), которые могут трогать и
> сисколлы (которые работают на других процах).
> .
> Здесь нужно отвлечься на то, что прерывания имеют разные уровни.
> Прерывания более высокого уровня могут прервать обрабатывающееся
> прерывание более низкого уровня. То есть рекурсивно вызваться (прервав
> выполнение более низкоуровневого), отработать, выйти, после этого проц
> вернётся к доисполнению "предыдущего прерванного прерывания".
> .
> Есть spl(9)-функции, которые позволяют блокировать прерывания
> заданного или более низкого уровня (то есть не дать им прервать
> выполнение кода, который в spl-обёртке), чтобы оградить некие куски от
> гонок с прерываниями. Сисколл работает на "самом низком spl уровне",
> то есть совсем без уровня, IPL_NONE.
> .
> Итак любое железное прерывание может прервать посреди дороги

не совсем посреди, потому как сискол может и IPL поднять.

> выполняющийся сисколл, поднять spl уровень и после этого ОТОБРАТЬ
> биглок у сисколла. При этом процесс (сисколл) блокируется и помечается
> как P_BIGLOCK. Когда прерывание закончится и выйдет, биглок будет
> возвращен этому процессу и он оживёт.
> Таким образом, сейчас в параллель могут работать:
>
> 1) - юзерспейс (он независимо работает на каждом проце, и тока на boot
> проце он может быть прерван прерыванием),
>
> 2) - сисколл без SY_NOLOCK - на любом проце (получил биглок и работает,),
>     - либо прерывание на boot проце (получило или отобрало биглок и работает).

только не между собой в параллель.

>
> 3) - сисколлЫ с SY_NOLOCK (но внутри него может быть mutex или rwlock
> - тут уже думайте сами) - на любом проце,
>     - на boot проце такой сисколл, понятно, тоже может быть прерван
> прерыванием, но на других процах сисколлы с SY_NOLOCK будут работать.
> Ну тут широкое поле, логически подумайте (например про сисколл
> блокируемый и неблокируемый).
>

блокируемый он с точки зрения юзерленда, в кернеле это было бы lockup.
все блокируещиеся вызывают tsleep и, отдавая биглок, уходят с процессора.
 
> Теперь собственно к software interrapt'у.
> Под конец обработки каждого прерывания (ещё до выхода), в spllower(),
> проверяется "а не зашедулил ли кто отложенный интеррапт?". И если таки
> зашедулил, то запускается соответствующий обработчик. Он работает всё
> ещё в контексте прерывания, собственно для того и шедулили. Во время
> работы он может (тут уже это я так понимаю, код ещё не смотрел)
> поднять свой spl уровень, когда делает что-то, что может вызвать гонки

с самого начала у них IPL > 0 (например 1).

> (например, обращается к тем же mbuf'ам, когда пихает таки пакет в

твой пример с mbuf'ами плохой.  я говорил про аллокацию mbuf'ов :-)
проще говорить про какие-нибудь очереди навроде ipintrq.

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

выход из прерывания будет раньше, иначе смысла в этих softintr'ах
не было бы.

> Будет освобождён биглок (или отдан процессору и процессу у
> которого его отобрали, который помечен P_BIGLOCK). Теперь boot проц
> переключается из контекста прерывания в контекст процесса и продолжает
> выполнять то на чём он там закончил.
>
>
> Большой спасиб Михаилу Белопухову, который помог всё разжевать и
> понять, а также всем остальным за наводки.

всегда пожалуйста.

> --
> engineer


Reply | Threaded
Open this post in threaded view
|

Re: SMP. Некоторые подробности.

Vladimir Kirillov-2
In reply to this post by Anton Maksimenkov-2
On 23:28 Tue 17 Feb, Mike Belopuhov wrote:
> On Tue, Feb 17, 2009 at 22:22 +0300, engineer wrote:
> > Для тех кто следит за тредом.
> а шо есть такие? :-)
есть, есть :)

> > Здесь нужно отвлечься на то, что прерывания имеют разные уровни.
> > Прерывания более высокого уровня могут прервать обрабатывающееся
> > прерывание более низкого уровня. То есть рекурсивно вызваться (прервав
> > выполнение более низкоуровневого), отработать, выйти, после этого проц
> > вернётся к доисполнению "предыдущего прерванного прерывания".
> > .

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

спасибо,
--
Vladimir Kirillov


Reply | Threaded
Open this post in threaded view
|

Re: SMP. Некоторые подробности.

Anton Maksimenkov-2
In reply to this post by Mike Belopuhov
Для тех кто следит за тредом.

Один момент, который мне покоя не давал, сложился в пазл. Итак, глядим сюда:
>> В опенбсд все прерывания "направлены" (настроены в APIC)
> более конкретно - в LAPIC.
>> на boot процессор.  Соответственно только он и прерывается.
Последняя фраза заставляла меня городить бредовейшие идеи... И пришёл
момент упомянуть такую важную вещь как

       М Н О Г О З А Д А Ч Н О С Т Ь

которая грубо говоря есть замена исполняющегося процесса другим. По
желанию процесса либо _принудительно_.
И эта самая многозадачность имеет основу прямо на железном уровне, в
процессоре (по крайней мере в Intel'ях). И пришлось мне сдувать пыль с
книжки по asm'у (не подумайте что я asm-программер, во всём виновато
любопытство, вот и купил когда-то, почитал), и снова вспоминать.

 Итак, краткий экскурс, очень примитивный. В Intel'овских процессорах
есть реальный режим (типа для DOS, но в нём происходит и начальная
загрузка) и защищённый режим, в который проц нужно переключать и в
котором есть много чего сложного (есть книжки на русском), и в том
числе, ЖЕЛЕЗНАЯ ПОДДЕРЖКА МНОГОЗАДАЧНОСТИ.
 В этом защищённом режиме процессор оперирует со всякими таблицами
дескрипторов GDT, LDT, IDT... и самое интересное, для каждой задачи
(ну грубо говоря для процесса, очень грубо) выделяется
СелекторСегментаЗадачи (TSS). В этом TSS хранится всё состояние
выполняющейся задачи и регистры. Таким образом, можно в любой момент
прервать задачу, а потом снова перейти на её TSS (jmp или call) и...
она начинает выполняться с прерванного места, как будто ничего и не
было.
 Есть 2 способа-варианта такого переключения. Во-первых, задача сама
может переключиться на TSS другой задачи - начнёт выполняться другая
задача, с начала или с прерванного места (что там у неё в TSS);
во-вторых там есть ещё вложенность, например когда "другая задача"
была вызвана кем-то (см. "во-первых"), поработала, и затем вызывает
iret (возврат), то начнёт опять работать та "кем-то", которая её
запустила.
 Так вот это дело как раз и эксплуатирует обработчик прерывания
таймера. Он делает такой финт ушами - загружает в TSS сегмент
выполняющейся задачи (_с_ которой надо переключиться, она "отработала
свой квант") информацию о том, что она якобы была вызвана из TSS
другой задачи (_на_ которую надо переключиться и дать ей поработать).
И вызывает инструкцию iret - получается, что "как бы" "от имени
выполняющейся задачи". Вуаля! Происходит как будто возврат из
вложенного вызова первой задачи обратно в вызвавшую, вторую задачу.
Выполняющаяся задача тормозится, и управление переходит на другую
задачу, якобы она вызывала выполняющуюся (теперь приторможенную).
Как-то так.
Итого: только обработчик прерывания по таймеру может переключать
задачи, т.к. он гарантированно периодически запускается.

Возвращаемся к bsd. Итак, чтобы выполнялась многозадачность необходимо
чтобы приходили прерывания от таймера, которые бы переключали задачи.
И они приходят, НА ВСЕ процессоры. Так что НА ВСЕХ процессорах
отрабатывается как минимум один hardware interrupt - от ТАЙМЕРА -
который и переключает задачи. Реализуется многозадачность.

Есть ещё какие-то прерывания :-)), но то, что приходит как минимум
"таймерское", лично мне очень важно было узнать для понимания "кто
кого дёргает".
>> Большой спасиб Михаилу Белопухову

P.S.
> а если наоборот, в момент прерывания высокого уровня приходит более
> низкое (которое как бы замаскировано), что с ним происходит? оно просто
> игнорируется? (где это можно посмотреть?)
Посмотреть можно наверное в "Pentium Processor Family Developer's
Manual" :-)). ИМХО, по логике, более низкоуровневое как минимум
однократно будет выполнено после того как завершится обработчик более
высокоуровневого. Но это чисто ИМХО.
--
engineer
Reply | Threaded
Open this post in threaded view
|

Re: SMP. Некоторые подробности.

Dinar Talypov
On Thu, 19 Feb 2009 10:59:17 +0500
engineer <[hidden email]> wrote:

> Для тех кто следит за тредом.
>
> Один момент, который мне покоя не давал, сложился в пазл. Итак, глядим сюда:
> >> В опенбсд все прерывания "направлены" (настроены в APIC)
> > более конкретно - в LAPIC.
> >> на boot процессор.  Соответственно только он и прерывается.
> Последняя фраза заставляла меня городить бредовейшие идеи... И пришёл
> момент упомянуть такую важную вещь как
>
>        М Н О Г О З А Д А Ч Н О С Т Ь
>
В кратце небольшое резюме написанному:

Многозадачности в железном уровне нет, по крайней мере на PC.
Многозадачность реализуется при помощи так называемого context switching, т.е.
на один процесс отдается определенный промежуток времени. Промежуток времени задает RTC(real time clock)( вернее ориентируясь на него,на его прерывания ведется отсчет времени), который генерирует прерывания, соответсвенно обрабатывая прерывания и процессор переключается на другую задачу.
Очередность выполнения задач определяется приоритетом данной задачи, управлется все это дело шедулером.

По поводу RTC в SMP:
Все прерывания в SMP обрабатываются через APIC, таймером для APIC и является RTC, как один из его источников прерываний
Если правильно понял вот это http://developer.intel.com/design/pentium/datashts/24201606.pdf

Если я ошибаюсь, поправьте.


--
Динар Талыпов


Reply | Threaded
Open this post in threaded view
|

Re: SMP. Некоторые подробности.

Alexander Yurchenko-3
On Thu, Feb 19, 2009 at 10:18:56AM +0300, Dinar Talypov wrote:
> Многозадачности в железном уровне нет, по крайней мере на PC.

Есть возможность иметь изолированные адресные пространства. Этого обычно
достаточно.

--
   Alexander Yurchenko


Reply | Threaded
Open this post in threaded view
|

Re: SMP. Некоторые подробности.

Dinar Talypov
On Thu, 19 Feb 2009 11:11:55 +0300
Alexander Yurchenko <[hidden email]> wrote:

> On Thu, Feb 19, 2009 at 10:18:56AM +0300, Dinar Talypov wrote:
> > Многозадачности в железном уровне нет, по крайней мере на PC.
>
> Есть возможность иметь изолированные адресные пространства. Этого обычно
> достаточно.
>
так это же по моему уже numa, или я ошибаюсь?

--
Динар Талыпов
т.+7(8555) 455010
ООО "Камател-Янтел"


Reply | Threaded
Open this post in threaded view
|

Re: SMP. Некоторые подробности.

Alexander Yurchenko-3
On Thu, Feb 19, 2009 at 11:31:31AM +0300, Dinar Talypov wrote:

> On Thu, 19 Feb 2009 11:11:55 +0300
> Alexander Yurchenko <[hidden email]> wrote:
>
> > On Thu, Feb 19, 2009 at 10:18:56AM +0300, Dinar Talypov wrote:
> > > Многозадачности в железном уровне нет, по крайней мере на PC.
> >
> > Есть возможность иметь изолированные адресные пространства. Этого обычно
> > достаточно.
> >
> так это же по моему уже numa, или я ошибаюсь?

Брррр. Давай сначала и по порядку. Для примера возьмем i386.

Один процессор, работает в реальном режиме. Есть многозадачность? Строго
говоря нет, в каждый момент времени работает только одна задача. Если
добавить второй процессор, может появиться многозадачность.

Однако многозадачность появилась до многопроцессорности. В чем же дело?
Современная многозадачность - фактически эмуляция оной за счет того, что
каждая задача прерывается через какое-то время работы, и начинает
работать другая. Если они прерываются довольно часто, создается иллюзия
многозадачности.

Теперь пусть задача, например, считает количество выполненных инструкций и
по достижении какого-то количества сохраняет свои регистры в стеке,
берет некий глобальный указатель на стек с сохраненными регистрами
другой задачи и восстанавливает их в себя - заработала другая задача.
Есть многозадачность - есть. Нужна аппаратная поддержка? Не нужна. Так
скажем работает libpthread в openbsd.

Далее, мы хотим, чтобы задачи сами переключались. Тогда мы делаем
прерывание от таймера и планировщик, который переключает задачи. Иллюзия
многозадачности еще сильнее стала (программист теперь не должен вызывать
yield() или его аналог, ему кажется, что в системе работает только его
задача, хотя на самом деле несколько). Нужна аппаратная поддержка? Ну
разве что таймер с прерыванием.

Далее, программист не хочет следить за распределением памяти, чтобы не
пересекаться с другими задачами. Тогда мы переходим в защищенный режим.
Теперь менеджер памяти в процессоре (mmu) знает, какая память
какой задаче принадлежит, и позволяет каждой задаче во-первых иметь
изолированное виртуальное адресное пространство, а во-вторых не лазить в
чужую память. Теперь иллюзия многозадачности совсем очень сильная,
программист вообще ни о чем не думает, и на одном процессоре
исполняется много задач. Нужна аппаратная поддержка? Да, наличие MMU.

>
> --
> Динар Талыпов
> т.+7(8555) 455010
> ООО "Камател-Янтел"
>

--
   Alexander Yurchenko


Reply | Threaded
Open this post in threaded view
|

Re: SMP. Некоторые подробности.

Mike Belopuhov
In reply to this post by Dinar Talypov
On Thu, Feb 19, 2009 at 11:31 +0300, Dinar Talypov wrote:

> On Thu, 19 Feb 2009 11:11:55 +0300
> Alexander Yurchenko <[hidden email]> wrote:
>
> > On Thu, Feb 19, 2009 at 10:18:56AM +0300, Dinar Talypov wrote:
> > > Многозадачности в железном уровне нет, по крайней мере на PC.
> >
> > Есть возможность иметь изолированные адресные пространства. Этого обычно
> > достаточно.
> >
> так это же по моему уже numa, или я ошибаюсь?
>

это еще virtual memory.  numa это memory locality.

> --
> Динар Талыпов
> т.+7(8555) 455010
> ООО "Камател-Янтел"
>
>


Reply | Threaded
Open this post in threaded view
|

Re: SMP. Некоторые подробности.

Anton Maksimenkov-2
In reply to this post by Dinar Talypov
Чисто для архива. NUMA ontopic, так что...

>> Есть возможность иметь изолированные адресные пространства. Этого обычно
>> достаточно.
> так это же по моему уже numa, или я ошибаюсь?

NUMA - это физический уровень, адресные пространства - логический.

http://www.ixbt.com/cpu/rmma-numa.shtml - тут упрощённая картинка что
такое NUMA в отличие от FSB.
NUMA - это отдельные модули физической памяти для каждого проца, на
его, отдельной, физической шине. FSB - физическая общая шина на
которой сидят все процы и вся память.

Изолированные адресные пространства, это, грубо говоря, когда каждая
программа думает что её память это ячейки от 0 до ххх. Но на самом
деле эта её память - виртуальная. И эти номера, через таблицу
дескрипторов (своя для каждой программы или там просто разные данные
для каждой задачи) преобразовываются процессором в реальные адреса в
физической памяти, которые уже соответственно получаются разные (в
общем случае) для разных программ. Как-то так. Но я бы и сам рад тему
asm'а закончить (если не, то хотя бы не в этом топике). asm в
книжках/доках по-русски есть много, нудно и неинтересно.
--
engineer
Reply | Threaded
Open this post in threaded view
|

Re: SMP. Некоторые подробности.

Stanislav Kruchinin
In reply to this post by Anton Maksimenkov-2
engineer wrote:
> Для тех кто следит за тредом.
>

Вы прямо-таки взорвали рассылку своей неуемной жаждой знаний. Лучше книгу
хорошую почитать по архитектуре Linux или Solaris, где в плане SMP уже сделано
все, что нужно.

>
> Есть ещё какие-то прерывания :-)), но то, что приходит как минимум
> "таймерское", лично мне очень важно было узнать для понимания "кто
> кого дёргает".

Точнее, обработчик прерывания от таймера дергает функцию schedule, которая
смотрит в очередь задач (task queue), определяет процесс, который будет
выполняться, и вызывает switch_mm и switch_to, чтобы переключиться на него.


12