Smp linux что это

Обновлено: 07.07.2024

Yes. Processes and kernel-threads are distributed among processors. User-space threads are not.

SMP is supported in 2.0 on the hypersparc (SS20, etc.) systems and Intel 486, Pentium or higher machines which are Intel MP1.1/1.4 compliant. Richard Jelinek adds: right now, systems have been tested up to 4 CPUs and the MP standard (and so Linux) theoretically allows up to 16 CPUs.

SMP support for UltraSparc, SparcServer, Alpha and PowerPC machines is in available in 2.2.x.

From Ralf B�chle :

MIPS, m68k and ARM does not support SMP; the latter two probly won't ever.

That is, I'm going to hack on MIPS-SMP as soon as I get a SMP box .

( Matti Aarnio ) The way Linux implements threads is to treat them at scheduling the same way as any process - thread just happens to share several resources of the originating process; memory space, file descriptors. See clone(2) for part of explanation.

Most Linux distributions don't provide a ready-made SMP-aware kernel, which means that you'll have to make one yourself. If you haven't made your own kernel yet, this is a great reason to learn how. Explaining how to make a new kernel is beyond the scope of this document; refer to the Linux Kernel Howto for more information. ( C. Polisher )

Configure the kernel and answer Y to CONFIG_SMP.

If you are using LILO, it is handy to have both SMP and non-SMP kernel images on hand. Edit /etc/lilo.conf to create an entry for another kernel image called "linux-smp" or something.

The next time you compile the kernel, when running a SMP kernel, edit linux/Makefile and change "MAKE=make" to "MAKE=make -jN" (where N = number of CPU + 1, or if you have tons of memory/swap you can just use "-j" without a number). Feel free to experiment with this one.

Of course you should time how long each build takes :-) Example:

If you are using some Compaq MP compliant machines you will need to set the operating system in the BIOS settings to "Unix

In kernel series 2.0 up to but not including 2.1.132, uncomment the SMP=1 line in the main Makefile ( /usr/src/linux/Makefile ).

In the 2.2 version, configure the kernel and answer "yes" to the question "Symmetric multi-processing support" ( Michael Elizabeth Chastain ).

enable real time clock support by configuring the "RTC support" item (in "Character Devices" menu) (from Robert G. Brown ). Note that inserting RTC support actually doesn't afaik prevent the known problem with SMP clock drift, but enabling this feature prevents lockup when the clock is read at boot time. A note from Richard Jelinek says also that activating the Enhanced RTC is necessary to get the second CPU working (identified) on some original Intel Mainboards.

(x86 kernel) do NOT enable APM (advanced power management)! APM and SMP are not compatible, and your system will almost certainly (or at least probably ;) ) crash while booting if APM is enabled ( Jakob Oestergaard ). Alan Cox confirms this : 2.1.x turns APM off for SMP boxes. Basically APM is undefined in the presence of SMP systems, and anything could occur.

(x86 kernel) enable "MTRR (Memory Type Range Register) support". Some BIOS are buggy as they do not activate cache memory for the second processor. The MTRR support contains code that solves such processor misconfiguration.

You must rebuild all your kernel and kernel modules when changing to and from SMP mode. Remember to make modules and make modules_install (from Alan Cox ).

If you get module load errors, you probably did not rebuild and/or re-install your modules. Also with some 2.2.x kernels people have reported problems when changing the compile from SMP back to UP (uni-processor). To fix this, save your .config file, do make mrproper , restore your .config file, then remake your kernel ( make dep , etc.) ( Wade Hampton ). Do not forget to run lilo after copying your new kernel.

In the 2.0 series, comment the SMP=1 line in the main Makefile (/usr/src/linux/Makefile).

In the 2.2 series, configure the kernel and answer "no" to the question "Symmetric multi-processing support" ( Michael Elizabeth Chastain ).

You must rebuild all your kernel and kernel modules when changing to and from SMP mode. Remember to make modules and make modules_install and remember to run lilo. See notes above about possible configuration problems.

Typical output (dual PentiumII):

Linux kernel version 2.2 has signal handling, interrupts and some I/O stuff fine grain locked. The rest is gradually migrating. All the scheduling is SMP safe.

Kernel version 2.3 (next 2.4) has really fine grained locking. In the 2.3 kernels the usage of the big kernel lock has basically disappeared, all major Linux kernel subsystems are fully threaded: networking, VFS, VM, IO, block/page caches, scheduling, interrupts, signals, etc. ( Ingo Molnar )

(Mark Hahn) In many parts of the kernel, there's little relation between 2.2 and 2.4. One of the biggest changes is SMP - not just the evolutionary fine-graining of locks, but the radically revamped VM, memory management, interrupt handling that's basically unrelated to 2.2, fairly revolutionary net changes (thread and zero-copy), etc.

In short, 2.2 doesn't use the hardware like 2.4 does.

No and Yes. There is no way to force a process onto specific CPU's but the linux scheduler has a processor bias for each process, which tends to keep processes tied to a specific CPU.

The goal of this project is to make a source compatible and functionally equivalent version of pset (as defined by SGI - partially removed from their IRIX 6.4 kernel) for Linux. This enables users to determine which processor or set of processors a process may run on. Possible uses include forcing threads to separate processors, timings, security (a `root' only CPU?) and probably more.

binding a process/thread to a specific CPU
restricting a CPU's ability to execute some processes
restricting a CPU from running at all
forcing a cpu to run _only_ one process (and its children)
getting information about a CPU's state
creating/destroying sets of processors, to which processes may be bound

Also have a look at this article by Bryant, Hartner, Qi and Venkitachalam that compares 2.2 and 2.3/2.4 UP and SMP kernels : SMP Scalability Comparisons of Linux� Kernels 2.2.14 and 2.3.99 ( Ray Bryant ) (You'll find also a copy here)

If you have to ask, you probably don't. :) Generally, multi-processor systems can provide better performance than uni-processor systems, but to realize any gains you need to consider many other factors besides the number of CPU's. For instance, on a given system, if the processor is generally idle much of the time due to a slow disk drive, then this system is "input/output bound", and probably won't benefit from additional processing power. If, on the other hand, a system has many simultaneously executing processes, and CPU utilization is very high, then you are likely to realize increased system performance. SCSI disk drives can be very effective when used with multiple processors, due to the way they can process multiple commands without tying up the CPU. ( C. Polisher )

This depends on the application, but most likely not. SMP adds some overhead that a faster uniprocessor box would not incur ( Wade Hampton ). :)

Thanks to Samuel S. Chessman , here are some useful utilities: Character based:

Basically, it's procps v1.12.2 (top, ps, et. al.) and some patches to support SMP.

xosview-1.5.1 supports SMP. And kernels above 2.1.85 (included) the cpuX entry in /proc/stat file.

By the way, you can't monitor processor scheduling precisely with xosview, as xosview itself causes a scheduling perturbation. ( H. Peter Anvin )

And Rik van Riel tell us why:

the cpu hog (low scheduling priority because it eats CPU)
xosview
X

With a 2.2 like kernel, see also the file /usr/src/linux/Documentation/smp.txt for specific instruction.

BTW, since running multiple compilers allows a machine with sufficient memory to use use the otherwise wasted CPU time during I/O caused delays, make MAKE="make -j 2" -j 2 actually helps even on uniprocessor boxes (from Ralf B�chle ).

In the 2.0 series, the result given by the time command is false. The sum user+system is right *but* the spreading between user and system time is false.

More precisely: "The explanation is, that all time spent in processors other than the boot cpu is accounted as system time. If you time a program, add the user time and the system time, then you timing will be almost right, except for also including the system time that is correctly accounted for" ( Jakob �stergaard ).

This bug is corrected in 2.2 kernels.

Section by Jakob �stergaard .

This section is intended to outline what works, and what doesn't when it comes to programming multi-threaded software for SMP Linux.

Parallelization methods

POSIX Threads
PVM / MPI Message Passing Libraries
fork() -- Multiple processes

Since both fork() and PVM/MPI processes usually do not share memory, but either communicate by means of IPC or a messaging API, they will not be described further in this section. They are not very specific to SMP, since they are used just as much - or more - on uniprocessor computers, and clusters thereof.

Only POSIX Threads provide us with multiple threads sharing ressources like - especially - memory. This is the thing that makes a SMP machine special, allowing many processors to share their memory. To use both (or more ;) processors of an SMP, use a kernel-thread library. A good library is the LinuxThreads, a pthread library made by Xavier Leroy which is now integrated with glibc2 (aka libc6). Newer Linux distributions include this library by default, hence you do not have to obtain a separate package to use kernel threads.

There are implementations of threads (and POSIX threads) that are application-level, and do not take advantage of the kernel-threading. These thread packages keep the threading in a single process, hence do not take advantage of SMP. However, they are good for many applications and tend to actually run faster than kernel-threads on single processor systems.

Multi-threading has never been really popular in the UN*X world though. For some reason, applications requiring multiple processes or threads, have mostly been written using fork(). Therefore, when using the thread approach, one runs into problems of incompatible (not thread-ready) libraries, compilers, and debuggers. GNU/Linux is no exception to this. Hopefully the next few sections will sched a little light over what is currently possible, and what is not.

The C Library

Older C libraries are not thread-safe. It is very important that you use GNU LibC ( glibc ), also known as libc6 . Earlier versions are, of course possible to use, but it will cause you much more trouble than upgrading your system will, well probably :)

If you want to use GDB to debug your programs, see below.

Languages, Compilers and debuggers

There is a wealth of programming languages available for GNU/Linux, and many of them can be made to use threads one way or the other (some languages like Ada and Java even have threads as primitives in the language).

This section will, however, currently only describe C and C++. If you have experience in SMP Programming with other languages, please enlighten us.

GNU C and C++, as well as the EGCS C and C++ compilers work with the thread support from the standard C library ( glibc ). There are however a few issues:

When compiling C or C++, use the -D_REENTRANT define in the compiler command line. This is necessary to make certain error-handling functions work like the errno variable.
When using C++, If two threads throw exceptions concurrently, the program will segfault. The compiler does not generate thread-safe exception code. The workaround is to put a pthread_mutex_lock(&global_exception_lock) in the constructor(s) of every class you throw(), and to put the corresponding pthread_mutex_unlock(. ) in the destructor. It's ugly, but it works. This solution was given by Markus Ferch .

The GNU Debugger GDB as of version 4.18, should handle threads correctly. Most Linux distribution offer a patched, thread-aware gdb.

It is not necessary to patch glibc in any way just to make it work with threads. If you do not need to debug the software (this could be true for all machines that are not development workstations), there is no need to patch glibc .

Note that core-dumps are of no use when using multiple threads. Somehow, the core dump is attached to one of the currently running threads, and not to the program as a whole. Therefore, whenever you are debugging anything, run it from the debugger.

Hint: If you have a thread running haywire, like eating 100% CPU time, and you cannot seem to figure out why, here is a nice way to find out what's going on: Run the program straight from the shell, no GDB. Make the thread go haywire. Use top to get the PID of the process. Run GDB like gdb program pid . This will make GDB attach itself to the process with the PID you specified, and stop the thead. Now you have a GDB session with the offending thread, and can use bt and the like to see what is happening.

Other libraries

ElectricFence: This library is not thread safe. It should be possible, however, to make it work in SMP environments by inserting mutex locks in the ElectricFence code.

Other points about SMP Programming

Lots of useful information can be found at Parallel Processing using Linux

Yes. For programs, you should look at: Multithreaded programs on linux (I love hyperlinks, did you know that ? ;) )

OpenGL Mesa library

( Randy Dunlap ) Linux supports MPS (MP spec.) version 1.1 and 1.4.

Linux doesn't have full support for all of MPS version 1.4.

Experience has shown that Linux usually works best when the BIOS is configure for MP Spec. version 1.1 if that is an option in your system's BIOS. I don't see why the MP Spec. version should matter to Linux, but it would be an interesting exercise to find out the differences as presented by BIOS tables, to determine why Linux fails with MP Spec. version 1.4 in some cases, and to fix Linux so that this wouldn't matter.

This document summarizes the major changes in MP spec. version 1.4 and their support status in Linux.

Symmetric I/O Mode

The hardware must support a mode of operation in which the system can switch easily to Symmetric I/O mode from PIC or Virtual Wire mode. When the operating system is ready to swtich to MP operation, it writes a 01H to the IMCR register, if that register is implemented, and enables I/O APIC Redirection Table entries. The hardware must not require any other action on the part of software to make the transition to Symmetric I/O mode.

Linux recognizes and supports this MP configuration mode.

Floating Point Exception Interrupt

For PC/AT compatibility, the bootstrap processor must support DOS-compatible FPU execution and exception handling while running in either of the PC/AT-compatible modes. This means that floating point error signals from the BSP must be routed to the interrupt request 13 signal, IRQ13, when the system is in PIC or virtual wire mode. While floating point error signals from an application processor need not be routed to IRQ13, platform designers may choose to connect the two. For example, connecting the floating point error signal from application processors to IRQ13 can be useful in the case of a platform that supports dynamic choice of BSP during boot.

In symmetric mode, a compliant system supports only on-chip floating point units, with error signaling via interrupt vector 16. Operating systems must use interrupt vector 16 to manage floating point exceptions when the system is in symmetric mode.

Multiple I/O APIC Configurations

Multiple I/O APICs are supported in Linux.

MP Configuration Table

This table was made optional in MPS version 1.4. If the table isn't present, one of the default configurations should be used. An extended section was also added to it for new table entry types.

Linux supports the optional MP Configuration Table and uses a default configuration if the MP Config. Table is not present.

Linux tolerates extended section table entries by skipping over them if they are found. Data in the extended table entries is not used.

MP Configuration Table Header Fields

New or changed fields for MP Spec. version 1.4:

OEM Table Pointer: supported in Linux
Extended Table Length: supported (tolerated, skipped) in Linux
Extended Table Checksum: supported (tolerated, skipped) in Linux

Extended MP Configuration Table Entries

Entry types for System Address Space Mapping, Bus Hierarchy Descriptor, and Compatibility Bus Address Space Modifier are defined.

Linux skips over (does not use) these extended MP Configuration table entries. Apparently this isn't critical to any shipping systems.

Те, кто когда-нибудь изучал архитектуру ЭВМ знает, что процессор сам по себе не умеет выполнять несколько задач сразу, многозадачность нам даёт только ОС, которая и переключает эти задачи. Есть несколько типов многозадачности, но самый адекватный, удобный и широко используемый — вытесняющая многозадачность(главные её аспекты Вы можете прочитать на википедии). Она основана на том, что у каждого процесса(задачи) есть свой приоритет, который влияет на то, сколько процессорного времени ему будет выделено. Каждой задаче даётся один квант времени, во время которого процесс что-либо делает, после истечение кванта времени ОС передает управление другой задаче. Возникает вопрос — а как распределить ресурсы компьютера, такие, как память, устройства и т.п. между процессами? Всё очень просто: Windows делает это сама, Linux же использует систему семафоров. Но одно ядро — несерьезно, идем дальше.

Прерывания и PIC

Как вы наверное поняли, прерывания — это функции(или же процедуры), которые вызываются в какой-либо момент времени оборудованием, или же самой программой. Всего процессор поддерживает 16 прерываний на двух PIC'ах. Процессор имеет флаги, и один из них — флаг «I» — Interrupt Control. Путем установки данного флага в 0 процессор не будет вызывать никаких аппаратных прерываний. Но, так же хочу заметить, что есть так называемые NMI — Non-Maskable Interrupts — данные прерывания всё равно будут вызываться, даже если бит I установлен в 0. При помощи программирования PIC можно запретить данные прерывания, но после возврата из любого прерывания при помощи IRET — они вновь станут не запрещенными. Замечу, что из-под обычной программы вы не сможете отследить вызов прерывания — выполнение вашей программы остановиться, и только через некоторое время возобновиться, ваша программа этого даже не заметит(да-да, можно проверить то, что было вызвано прерывание — но зачем?

PIC — Programmable Interrupt Controller

Как правило, представляет собой электронное устройство, иногда выполненное как часть самого процессора или же сложных микросхем его обрамления, входы которого присоединены электрически к соответствующим выходам различных устройств. Номер входа контроллера прерываний обозначается «IRQ». Следует отличать этот номер от приоритета прерывания, а также от номера входа в таблицу векторов прерываний (INT). Так, например, в IBM PC в реальном режиме работы (в этом режиме работает MS-DOS) процессора прерывание от стандартной клавиатуры использует IRQ 1 и INT 9.

В первоначальной платформе IBM PC используется очень простая схема прерываний. Контроллер прерываний представляет собой простой счётчик, который либо последовательно перебирает сигналы разных устройств, либо сбрасывается на начало при нахождении нового прерывания. В первом случае устройства имеют равный приоритет, во втором устройства с меньшим (или большим при обратном счёте) порядковым номером обладают большим приоритетом.

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

Теперь же, давайте перейдем к самой теме статьи.

Для реализации данного стандарта на материнские платы начали ставить новые схемы: APIC и ACPI. Давайте поговорим о первом.

APIC — Advanced Programmable Interrupt Controller, улучшенная версия PIC. Он используется в многопроцессорных системах и является неотъемлемой частью всех последних процессоров Intel (и совместимых). APIC используется для сложного перенаправления прерываний и для отправки прерываний между процессорами. Эти вещи были невозможны с использованием более старой спецификации PIC.

Local APIC и IO APIC

В системе на базе APIC каждый процессор состоит из «ядра» и «локального APIC'а». Local APIC отвечает за обработку конфигурации прерываний, специфичных для процессора. Помимо всего прочего, он содержит локальную векторную таблицу (LVT), которая переводит события, такие как «внутренние часы(internal clock)» и другие «локальные» источники прерываний, в вектор прерывания (например, контакт LocalINT1 может поднимать исключение NMI, сохраняя «2» в соответствующий вход LVT).

Более подробную информацию о локальном APIC можно найти в «Руководстве по системному программированию» современных процессоров Intel.

Кроме того, имеется APIC IO (например, intel 82093AA), который является частью набора микросхем и обеспечивает многопроцессорное управление прерываниями, включающее как статическое, так и динамическое симметричное распределение прерываний для всех процессоров. В системах с несколькими подсистемами ввода / вывода каждая подсистема может иметь свой собственный набор прерываний.

Каждый вывод прерывания индивидуально программируется «as either edge or level triggered». Вектор прерывания и информация об управлении прерываниями могут быть указаны для каждого прерывания. Схема косвенного доступа к регистру оптимизирует пространство памяти, необходимое для доступа к внутренним регистрам ввода-вывода APIC. Чтобы повысить гибкость системы при назначении использования пространства памяти, пространство двух регистров ввода-вывода APIC является перемещаемым, но по умолчанию оно равно 0xFEC00000.

Инициализация «локального» APIC'а

Локальный APIC активируется во время загрузки и может быть отключен путем сброса бита 11 IA32_APIC_BASE (MSR) (это работает только с процессорами с семейством > 5, поскольку у Pentium нет такого MSR), Затем процессор получает свои прерывания непосредственно из совместимого с 8259 PIC'а. Однако в руководстве Intel по разработке программного обеспечения указано, что после отключения локального APIC'а через IA32_APIC_BASE вы не сможете включить его до полного сброса. IO APIC также может быть сконфигурирован для работы в унаследованном режиме, так чтобы он эмулировал устройство 8259.

Отключите 8259 PIC правильно. Это почти так же важно, как настройка APIC. Вы делаете это в два этапа: маскирование всех прерываний и переназначение IRQ. Маскировка всех прерываний отключает их в PIC. Ремаппинг прерываний — это то, что вы, вероятно, уже сделали, когда вы использовали PIC: вы хотите, чтобы запросы прерывания начинались с 32 вместо 0, чтобы избежать конфликтов с исключениями(в защищенном и длинном(Long) режимах процессора, т.к. первые 32 прерывания — исключения(exceptions)). Затем вы должны избегать использования этих векторов прерываний для других целей. Это необходимо, потому что, несмотря на то, что вы маскировали все прерывания PIC, он все равно мог выдавать ложные прерывания, которые затем будут неверно обрабатываться в вашем ядре в качестве исключений.
Перейдем к SMP.

Симметричная многозадачность: инициализация

Последовательность запуска различна для разных ЦП. Руководство программиста Intel (раздел 7.5.4) содержит протокол инициализации для процессоров Intel Xeon и не охватывает более старые процессоры. Для общего алгоритма «всех типов процессоров» см. «Многопроцессорная спецификация Intel».

Для 80486 (с внешним APIC 8249DX) вы должны использовать IPIT INIT, за которым следует IPI «INIT level de-assert» без каких-либо SIPI. Это означает, что вы не можете сказать им, где начать выполнение вашего кода (векторная часть SIPI), и они всегда начинают выполнять код BIOS. В этом случае вы устанавливаете значение сброса CMOS BIOS в «warm start with far jump» (т. е. Установите положение CMOS 0x0F в значение 10), чтобы BIOS выполнил jmp far

[0: 0x0469] », а затем установите сегмент и смещение точки входа AP в 0x0469.

«INIT level de-assert» IPI не поддерживается на новых процессорах (Pentium 4 и Intel Xeon), а AFAIK полностью игнорируется на этих процессорах.

Для более новых процессоров (P6, Pentium 4) достаточно одного SIPI, но я не уверен, что более старые процессоры Intel (Pentium) или процессоры других производителей нуждаются в втором SIPI. Также возможно, что второй SIPI существует в случае сбоя доставки для первого SIPI (шум шины и т. д.).

Обычно я отправляю первый SIPI, а затем жду, чтобы увидеть, увеличивает ли AP счетчик количества запущенных процессоров. Если он не увеличит этот счетчик в течение нескольких миллисекунд, я отправлю второй SIPI. Это отличается от общего алгоритма Intel (который имеет задержку в 200 микросекунд между SIPI), но попытка найти источник времени, способный точно измерять задержку в 200 микросекунд во время ранней загрузки, не так-то просто. Я также обнаружил, что на реальном оборудовании, если задержка между SIPI слишком длинная (и вы не используете мой метод), главный AP может запускать ранний код запуска AP для ОС дважды (что в моем случае приведет к тому, что ОС будет думать, что мы имеем в два раза больше процессоров, чем есть на самом деле).

Вы можете транслировать эти сигналы по шине для запуска каждого присутствующего устройства. Однако при этом вы также можете включить процессоры, которые были отключены специально (потому что они были «дефектными»).

Ищем информацию, используя MT-таблицу

Некоторая информация (которая может отсутствовать на более новых машинах), предназначенная для многопроцессорности. Сначала нужно найти структуру плавающего указателя MP. Он выровнен по 16-байтовой границе и содержит подпись в начале «_MP_» или 0x5F504D5F. ОС должна искать в EBDA, пространстве BIOS ROM и в последнем килобайте «базовой памяти»; размер базовой памяти указан в 2-байтовом значении в 0x413 в килобайтах, минус 1 КБ. Вот как выглядит структура:

Вот как выглядит таблица конфигурации, на которую указывает плавающая структура указателя:

После таблицы конфигурации лежат записи entry_count, которые содержат больше информации о системе, после чего идет расширенная таблица. Записи представляют собой либо 20 байт для представления процессора, либо 8 байт для чего-то другого. Вот как выглядят записи процессора и ввода-вывода APIC.

Вот запись IO APIC.

Ищем информацию при помощи APIC

Вы можете найти таблицу MADT (APIC) в ACPI. В таблице приведен список локальных APIC, число которых должно соответствовать количеству ядер на вашем процессоре. Подробностей этой таблицы здесь нет, но вы можете найти их в интернете.

Запуск AP

После того, как вы собрали информацию, вам необходимо отключить PIC и подготовиться к APIC I/O. Вам также необходимо настроить BSP локального APIC'а. Затем запустите AP с использованием SIPI.

Код для запуска ядер:

Замечу, что вектор, который вы указываете при запуске говорит о начальном адресе: вектор 0x8 — адрес 0x8000, вектор 0x9 — адрес 0x9000 и т.п.

Теперь, как вы понимаете, чтобы ОС использовать много ядер, надо настроить стек для каждого ядра, каждое ядро, его прерывания и т.п., но самое важное — при использовании симметричной мультипроцессорности все ресурсы у ядер одни и те же: одна память, один PCI и т.п., и ОС остаётся лишь распараллелить задачи между ядрами.

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

В таксономии Флинна SMP-машины относятся к классу SM-MIMD-машин. Большинство многопроцессорных систем сегодня используют архитектуру SMP.

Содержание

Описание

SMP-системы позволяют любому процессору работать над любой задачей независимо от того, где в памяти хранятся данные для этой задачи, — при должной поддержке операционной системой SMP-системы могут легко перемещать задачи между процессорами, эффективно распределяя нагрузку.

Разные SMP-системы соединяют процессоры с общей памятью по-разному. Самый простой и дешевый подход — это соединение по общей шине (system bus). В этом случае только один процессор может обращаться к памяти в каждый данный момент, что накладывает существенное ограничение на количество процессоров, поддерживаемых в таких системах. Чем больше процессоров, тем больше нагрузка на общую шину, тем дольше должен ждать каждый процессор, пока освободится шина, чтобы обратиться к памяти. Снижение общей производительности такой системы с ростом количества процессоров происходит очень быстро, поэтому обычно в таких системах количество процессоров не превышает 2-4. Примером SMP-машин с таким способом соединения процессоров являются любые многопроцессорные серверы начального уровня.

Диаграмма устройства системы с симметричной мультипроцессорностью. Процессоры обращаются к общей памяти по общей шине

Преимущества и недостатки

SMP — самый простой и экономически выгодный способ масштабирования вычислительной системы: путём наращивания числа процессоров. Также просто и программирование: с помощью потоков и сопутствующих механизмов обмена данными между ними через общие переменные в памяти.

SMP часто применяется в науке, промышленности, бизнесе, где программное обеспечение специально разрабатывается для многопоточного выполнения. В то же время большинство потребительских продуктов, таких как текстовые редакторы и компьютерные игры, написаны так, что они не могут использовать сильные стороны SMP-систем. В случае игр это зачастую связано с тем, что оптимизация программы под SMP-системы приведёт к потере производительности при работе на однопроцессорных системах, которые еще недавно занимали большую часть рынка. (Современные многоядерные процессоры — лишь еще одна аппаратная реализация SMP.) В силу природы разных методов программирования для максимальной производительности потребуются отдельные проекты для поддержки одного процессора (одноядерного процессора) и SMP-систем. И все же программы, запущенные на SMP-системах, получают незначительный прирост производительности, даже если они были написаны для однопроцессорных систем. Это связано с тем, что аппаратные прерывания, обычно приостанавливающие выполнение программы для их обработки ядром, могут обрабатываться на свободном процессоре. Эффект в большинстве приложений проявляется не столько в приросте производительности, сколько в ощущении, что программа выполняется более плавно. В некоторых прикладных программах, в частности, программных компиляторах и некоторых проектах распределённых вычислений, повышение производительности будет почти прямо пропорционально числу дополнительных процессоров.

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

Ограничение на количество процессоров

При увеличении числа процессоров заметно увеличивается требование к полосе пропускания шины памяти. Это налагает ограничение на количество процессоров в SMP архитектуре. Современные SMP-системы позволяют эффективно работать при 16 процессорах.

Проблема когерентности кэш-памяти

Каждый современный процессор оборудован многоуровневой кэш-памятью для более быстрой выборки данных и инструкций из основной памяти, которая работает медленнее, чем процессор. В многопроцессорной системе наличие кэш-памяти у процессоров снижает нагрузку на общую шину или на коммутируемое соединение, что весьма благоприятно сказывается на общей производительности системы. Но, так как каждый процессор оборудован своей индивидуальной кэш-памятью, возникает опасность, что в кэш-память одного процессора попадет значение переменной отличное от того, что хранится в основной памяти и в кэш-памяти другого процессора. Представим, что процессор изменяет значение переменной в своем кэше, а другой процессор запрашивает эту переменную из основной памяти. И он получит старое значение переменной. Или, например, подсистема ввода-вывода записывает в основную память новое значение переменной, а в кэш-памяти процессора по-прежнему остается старое. Разрешение этой проблемы возложено на протокол согласования кэшей (cache coherence protocol), который призван обеспечить согласованность («когерентность») кэшей всех процессоров и основной памяти без потери общей производительности.

Поддержка операционной системой

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

Поддержка многопроцессорности в ОС Linux была добавлена в версии ядра 2.0 и усовершенствована в версии 2.6. ОС Windows NT изначально создавалась с поддержкой многопроцессорности. Но вот Windows 9x не поддерживали SMP до выхода Windows XP, ставшей развитием Windows 2000, т.е. ветки Windows NT.

Альтернативы

SMP — лишь один вариант построения многопроцессорной машины. Другая концепция — NUMA, которая предоставляет процессорам отдельные банки памяти. Это позволяет процессорам работать с памятью параллельно, и это может значительно повысить пропускную способность памяти в случае когда данные привязаны к конкретному процессу (а, следовательно, и процессору). С другой стороны, NUMA повышает стоимость перемещения данных между процессорами, значит, и балансирование загрузки обходится дороже. Преимущества NUMA ограничены специфическим кругом задач, в основном серверами, где данные часто жестко привязаны к конкретным задачам или пользователям.

Другая концепция — асимметричное мультипроцессирование (ASMP), в котором отдельные специализированные процессоры используются для конкретных задач, и кластерная мультипроцессорность (Beowulf), в которой не вся память доступна всем процессорам. Такие подходы нечасто используются (хотя высокопроизводительные 3D-чипсеты в современных видеокартах могут рассматриваться как форма асимметричной мультипроцессорности), в то время как кластерные системы широко применяются при построении очень больших суперкомпьютеров.

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

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

Один поток команд, один поток данных (SISD -- Single Instruction, Single Data) -- типичная однопроцессорная архитектура. Многопроцессорная архитектура Много потоков команд, много потоков данных (MIMD -- Multiple Instruction, Multiple Data) содержит отдельные процессоры, оперирующие независимыми данными (параллелизм управления). Наконец, Один поток команд, много потоков данных (SIMD -- Single Instruction, Multiple Data) имеет ряд процессоров, оперирующих разнотипными данными (параллелизм данных).

Многопроцессорная обработка зародилась в середине 1950-х в ряде компаний, некоторые из которых вы знаете, а некоторые, возможно, уже забыли (IBM, Digital Equipment Corporation, Control Data Corporation). В начале 1960-х Burroughs Corporation представила симметричный мультипроцессор типа MIMD с четырьмя CPU, имеющий до шестнадцати модулей памяти, соединенных координатным соединителем (первая архитектура SMP). Широко известный и удачный CDC 6600 был представлен в 1964 и обеспечивал CPU десятью подпроцессорами (периферийными процессорами). В конце 1960-х Honeywell выпустил другую симметричную мультипроцессорную систему из восьми CPU Multics.

В то время как многопроцессорные системы развивались, технологии также шли вперед, уменьшая размеры процессоров и увеличивая их способности работать на значительно большей тактовой частоте. В 1980-х такие компании, как Cray Research, представили многопроцессорные системы и UNIX®-подобные операционные системы, которые могли их использовать (CX-OS).

В конце 1980-х с популярностью однопроцессорных персональных компьютеров, таких как IBM PC, наблюдался упадок в многопроцессорных системах. Но сейчас, двадцать лет спустя, многопроцессорная обработка вернулась к тем же самым персональным компьютерам в виде симметричной многопроцессорной обработки.

Джин Амдаль (Gene Amdahl), компьютерный архитектор и сотрудник IBM, разрабатывал в IBM компьютерные архитектуры, создал одноименную фирму, Amdahl Corporation и др. Но известность ему принес его закон, в котором рассчитывается максимально возможное улучшение системы при улучшении ее части. Закон используется, главным образом, для вычисления максимального теоретического улучшения работы системы при использовании нескольких процессоров (смотри Рисунок 1).

Используя уравнение, показанное на Рисунке 1, вы можете вычислить максимальное улучшение производительности системы, использующей N процессоров и фактор F , который указывает, какая часть системы не может быть распараллелена (часть системы, которая последовательна по своей природе). Результат приведен на Рисунке 2.

Верхняя линия на Рисунке 2 показывает число процессоров. В идеале это то, что вы хотели бы увидеть после добавления дополнительных процессоров для решения задачи. К сожалению, из-за того что не все в задаче может быть распараллелено и есть непроизводительные издержки в управлении процессорами, ускорение оказывается немного меньше. Внизу (лиловая линия) -- случай задачи, которая на 90% последовательна. Лучшему случаю на этом графике соответствует коричневая линия, которая изображает задачу, которая на 10% последовательна и, соответственно, на 90% -- параллелизуема. Даже в этом случае десять процессоров работают совсем не намного лучше, чем пять.

Архитектура SMP -- одна из тех, где два или более идентичных процессоров соединены друг с другом посредством разделяемой памяти. У всех них одинаковый доступ к разделяемой памяти (одинаковое время ожидания доступа к пространству памяти). Противоположностью ей является архитектура неоднородного доступа к памяти (NUMA -- Non-Uniform Memory Access). Например, у каждого процессора есть своя собственная память и доступ к разделяемой памяти с разным временем ожидания.

Ранние SMP системы Linux были слабосвязанными многопроцессорными системами, то есть построенными из нескольких отдельных систем, связанных высокоскоростным соединением (таким как 10G Ethernet, Fibre Channel или Infiniband). Другое название такого типа архитектуры -- кластер (смотрите Рисунок 3), для которого популярным решением остается проект Linux Beowulf. Кластеры Linux Beowulf могут быть построены из доступного оборудования и обычного сетевого соединения, такого как Ethernet.

Построение систем со слабосвязанной многопроцессорной архитектурой просто (спасибо проектам вроде Beowulf), но имеет свои ограничения. Создание большой многопроцессорной сети может потребовать значительных мощностей и места. Более серьезное препятствие -- материал канала связи. Даже с высокоскоростной сетью, такой как 10G Ethernet, есть предел масштабируемости системы.

Сильносвязанная многопроцессорная обработка относится к обработке на уровне кристалла (CMP -- chip-level multiprocessing). Представьте слабосвязанную архитектуру, уменьшенную до уровня кристалла. Это и есть идея сильносвязанной многопроцессорной обработки (также называемой многоядерным вычислением). На одной интегральной микросхеме несколько кристаллов, общая память и соединение образуют хорошо интегрированное ядро для многопроцессорной обработки (смотрите Рисунок 4).

Процессорные межсоединения
Другой параметр соединения (шина для системной матрицы) -- HyperTransport фирмы AMD. Intel® также планирует новое межсоединение под названием Common System Interface, которое ожидается в 2008.

Рисунок 4. Сильносвязанная архитектура многопроцессорной обработки

В CMP несколько CPU связаны общей шиной с разделяемой памятью (кэш второго уровня). Каждый процессор также имеет свою собственную быстродействующую память (кэш первого уровня). Сильносвязанная природа CMP позволяет очень короткие физические расстояния между процессорами и памятью и, вследствие этого, минимальное время ожидания доступа к памяти и более высокую производительность. Такой тип архитектуры хорошо работает в многопоточных приложениях, где потоки могут быть распределены между процессорами и выполняться параллельно. Это называется параллелизм на уровне потоков (TPL -- thread-level parallelism).

Принимая во внимание популярность этой многопроцессорной архитектуры, многие производители выпускают устройства CMP. В Таблице 1 приведены некоторые популярные варианты с поддержкой Linux.

Таблица 1. Выборка устройств CMP

Производитель	Устройство	Описание
IBM	POWER4	SMP, два CPU
IBM	POWER5	SMP, два CPU, четыре параллельных потока
AMD	AMD X2	SMP, два CPU
Intel®	Xeon	SMP, два или четыре CPU
Intel	Core2 Duo	SMP, два CPU
ARM	MPCore	SMP, до четырех CPUs
IBM	Xenon	SMP, три Power PC CPU
IBM	Cell Processor	Асимметричная многопроцессорная обработка (ASMP --Asymmetric multiprocessing), девять CPU

Для того чтобы использовать SMP с Linux на совместимом с SMP оборудовании, необходимо правильно настроить ядро. Опция CONFIG_SMP должна быть включена во время настройки ядра, чтобы ядро знало об SMP. Если такое ядро будет работать на многопроцессорном хосте, вы сможете определить количество процессоров и их тип с помощью файловой системы proc.

Сначала вы получаете число процессоров из файла cpuinfo в /proc, используя grep . Как видно из Листинга 1, вы используете опцию -- счетчик ( -c ) строк, начинающихся со слова processor . Приведено также содержимое файла cpuinfo . В качестве примера взята материнская плата Xeon на двух кристаллах.

Когда только появился Linux 2.0, поддержка SMP состояла из основной системы блокировки, которая упорядочивала доступ в системе. Позднее небольшой прогресс в поддержке SMP был, но только с ядром 2.6 наконец проявилась вся сила SMP.

Ядро 2.6 представило новый 0(1) планировщик, который включал лучшую поддержку для систем SMP. Ключевой была возможность балансировать нагрузку на все доступные CPU, по мере сил избегая переключения процессов между процессорами для более эффективного использования кэша. Что касается производительности кэша, вспомните из Рисунка 4, что когда задача взаимодействует с одним CPU, перемещение ее на другой требует вовлечения кэша. Это увеличивает время ожидания доступа к памяти задачи, пока ее данные находятся в кэше нового CPU.

SMP в ядре
Чтобы понять, как SMP инициализируется для заданной архитектуры, посмотрите файлы smp.c или smpboot.c внутри ядра, ./linux/arch/<arch>/kernel/ (для большинства архитектур и платформ).

Ядро 2.6 сохраняет пару runqueue для каждого процессора (истекший и активный runqueue). Каждый runqueue поддерживает 140 приоритетов, из которых 100 используется для задач в реальном времени, а остальные 40 для пользовательских задач. Задачам даются отрезки времени для выполнения, а когда они используют свое время, они перемещаются из активного runqueue в истекший. Таким образом осуществляется равноправный доступ к CPU для всех задач (блокировка только отдельных CPU).

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

В ядре Linux была проделана большая работа для развития SMP, но операционной системы, самой по себе, недостаточно. Вспомните, что сила SMP заключается в TLP. Отдельные монолитные (одно-поточные) программы не могут использовать SMP, но SMP может использоваться в программах, которые состоят из многих потоков, которые могут быть распределены между ядрами. Пока один поток ожидает выполнения операции I/O, другой может делать полезную работу. Таким образом, потоки работают, перекрывая время ожидания друг друга.

Потоки стандарта Portable Operating System Interface (POSIX) (интерфейс переносимой операционной системы) являются прекрасным способом построить поточные приложения, которые могут использовать SMP. Потоки стандарта POSIX обеспечивают механизм работы с потоками, а также общую память. Когда программа активизируется, создается некоторое количество потоков, каждый из которых поддерживает свой собственный стек (локальные переменные и состояние), но разделяет пространство данных родителя. Все созданные потоки разделяют это же самое пространство данных, но именно здесь кроется проблема.

Чтобы поддерживать многопоточный доступ к разделяемой памяти, требуются механизмы координирования. POSIX предоставляет функцию взаимного исключения для создания критических секций , которые устанавливают исключительный доступ к объекту (участку памяти) только для одного потока. Если этого не сделать, может повредиться память из-за несинхронизованных манипуляций, производимых несколькими потоками. Листинг 2 иллюстрирует создание критической секции с помощью взаимного исключения POSIX.

Листинг 2. Использование pthread_mutex_lock и unlock для создания критических секций

Если несколько потоков пытаются заблокировать семафор после начального вызова наверху, они блокируются, и их запросы ставятся в очередь, пока не выполнится вызов pthread_mutex_unlock .

Когда несколько ядер в процессоре работает параллельно для ядра ОС, желательно избегать совместного использования данных, которые специфичны для данного ядра процессора. По этой причине ядро 2.6 представило концепцию переменных для каждого ядра, которые связаны с отдельными CPU. Это позволяет объявлять переменные для CPU, которые наиболее часто используются именно этим CPU, что минимизирует требования блокировок и улучшает выполнение.

Определение переменных отдельного ядра производится при помощи макроса DEFINE_PER_CPU , которому вы передаете тип и имя переменной. Поскольку макрос поступает как l-value, здесь же вы можете инициализировать ее. В следующем примере (из ./arch/i386/kernel/smpboot.c) определяется переменная, представляющая состояние для каждого CPU в системе.

Макрос создает массив переменных, одну на каждый экземпляр CPU. Для получения переменной отдельного CPU используется макрос per_cpu вместе с функцией smp_processor_id , возвращающей текущий идентификатор CPU, для которого в данный момент выполняется программа.

Ядро предоставляет другие функции для блокировки каждого CPU и динамического выделения переменных. Эти функции можно найти в ./include/linux/percpu.h.

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

Системы SMP вы найдете не только на серверах, но и на десктопах, особенно с внедрением виртуализации. Как многие передовые технологии, Linux предоставляет поддержку для SMP. Ядро выполняет свою часть по оптимизации загрузки доступных CPU (от потоков до виртуализованных операционных систем). Все, что остается, это убедиться, что приложение может быть в достаточной мере разделено на потоки, чтобы использовать силу SMP.

Читайте также: