«Linux kernel in a nutshell» или коротко о ядре Линукс.

>Меньший объем монолитного ядра в ОЗУ, чем у модульного? - Да, на десятки, может сотню килобайт

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

> вы серьезно считаете, что на vanilla ядре один процесс не может открыть больше 256 файлов?

Забей. Ему уже показывали пример - но он его "ниасилил" :-(

> на вероятности 99%.

50%/50%

> И даже если это (1%) случится, уже установленный и настроенный софт будет работать, работать и работать - для многих ничего страшного.

Да, только вас поломают, а потом еще и еще и еще... Или ваши сервера не предоставляют сервисов, поэтому вы и не обновляетесь?

> If суппорт нужен для каких-то гарантий (Софт настроен и работает без апгрейдов) AND 99% вероятности мало AND нет своего суппорта - плати за большую вероятность. Есть много задач, где все 3 фактора не имеют места быть.

if(компания == серьезная) then { должен_быть_ответственный_за_оперативнейшее_устранение_проблем_в_софте_на_которо м_ делают_большие_бабки(); } else { IT_отдел = пионеры; }

> Софт халявный and opensource and без гарантий, но стоимость TCO для большинства такой расклад сильно сбивает.

Пераццкая венда тоже серьезно сокращает TCO с вероятностью 1% что за это что-то будет у таких же пионеров, которые рассчитываяч на халяву используют OSS, которое завтра может стать не OSS, а пользователи прокинуты и будут вынуждены сами сопровождать софт или покупать платную поддержку.

Давайте и я вставлю свои пять копеек. Раньше, во времена rh 7.2 вендорские дистры страшно сосали по скорости. Щас по субъективным ощущениям сильно большой разницы между gentoo и FC5 не заметил. Правда, я за самосборные ядра :). Хотя бы потому что мне в нем нужны некоторые патчи которых нет в обычных ядрах. Ну и я не заметил чтобы FC-шное ядро, к примеру, было стабилней, зато слышал и видел как это дело не заводилось на некоторых машинах вообще.

у современных ЦП кэш на две части разделён: код и данные, больше - по ссылке, что я выше приводил

>> на вероятности 99%.
>50%/50%

это уже "женская логика", вероятность встретить динозавра тоже 50/50 - либо встретишь, либо нет. 95% минимум, впрочем если боишься - плати за суппорт и спи спокойно.

>рассчитываяч на халяву используют OSS,
>которое завтра может стать не OSS,

грубая ошибка с твоей стороны, OSS всегда будет OSS. Не OSS может стать только софт написанный в будущем и только в том случае если у компании есть копирайт на весь код в этом софте. Если нет полного копирайта, то и будущие модификации софта под GPL они смогут выпускать только под GPL.

>а пользователи прокинуты

прокинуты будут только те, кто ошибочно думал что попал в коммунизм, и не удосужился прочитать пункт No Warranty в GPL.
FLOSS - это много халявы, но это не значит что все, что ты можешь пожелать тебе кто-то предоставит на халяву.

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

>Ну и ладно. А мы не такие крутые - мы поставим X-ы, и просто не станем >запускать X-сервер, и будет получать удовольствие от красивостей >инсталлера, и возложим рутиную работу на соответствующие тулзы.

про DISPLAY=my.working.machine.com:0 ты слышал?

Ты что серьезно ставишь на сервер с ораклом хксы? Тогда я присоединяюсь к совету анонимуса -убей себя -не порть породу.

> у современных ЦП кэш на две части разделён: код и данные, больше - по ссылке, что я выше приводил

А шин данных между процессором и контроллером памяти сколько? Две: одна - для кода, вторая для данных? :)

> Код это тоже данные, которые передаются из ОЗУ по шине данных.

Дружок, твои познания в схемотехнике устарели ровно на 20 (двадцать) лет. Изучи для начала темы "Конвейерная архитектура", "Суперскалярная архитектура", "RISC архитектура", "устройство выборки команд", "кеш инструкций", "декодер команд". После этого можешь пробовать пытаться умничать.

> А шин данных между процессором и контроллером памяти сколько? Две: одна - для кода, вторая для данных? :)

Гарвардская архитектура. Ага. Есть такое слово. И оно не матерное. Марш в школу, умник фигов.

>Одна проблема - собираться будет не несколько минут, а несколько часов, а так конечно, проблем нет :)

Хорош фигню городить ;)

ss@opteron2:~$ ulimit -u
4778

(ядро патченое под MOSIX - у него этот хардлимит примерно в полтора раза урезан по сравнению с 2.4 ванилой - max_threads/3 против обычных max_threads/2) у 2.6 хардлимит еще выше....

Пример - сборка 2.4.25 (лень новое тянуть) на 2xOpteron242+2Gb RAM

-j1 - 6:50
-j2 - 3:35
-j3 - 3:29
-j5 - 3:27
-j10 -3:20
-j100 -3:21
-j1000 - 3:28

так что у C2D оптимум будет тем более не при j=2

>ро DISPLAY=my.working.machine.com:0 ты слышал?

Куда уж мне о таком слышать. Угадай, будет ли это работать если на сервере не будет libX11.so и что по-твоему это такое если это не иксы.

> Дружок, твои познания в схемотехнике устарели ровно на 20 (двадцать) лет. Изучи для начала темы "Конвейерная архитектура", "Суперскалярная архитектура", "RISC архитектура", "устройство выборки команд", "кеш инструкций", "декодер команд". После этого можешь пробовать пытаться умничать.

Умник, какое отношение имеет декодер команд, конвейер и устройство кеша к КОНТРОЛЛЕРУ ПАМЯТИ? Где мля 2 отдельных шины, идущих к модулям памяти - одна для команд вторая для данных? Одновременно по шине может передаваться объем информации, соответсвующий ее разрядности, если шина на 64 бита, а 64 бита данных не выровнены, то данные потребуется пересылать по шине по частям, за два цикла. Для особо одаренных скажу: контроллер памяти не делает различий между кодом и данными, для него все что летит в/из ОЗУ по шине является просто данными. Или у тебя есть иная точка зрения? Заметь не было сказано ни слова про архитектуру кеш-памяти с отдельным кешем для данных и инструкций(либо uops). Так что впредь рекомендую сначала понять о чем говорят, и уже только после этого давать свои "ценные" указания.

>-j1000 - 3:28

>так что у C2D оптимум будет тем более не при j=2

Ага, сферический конь в ваккуме - при небольшой нагрузке (дисковые операции) на тестовую машину и полном отсутствии файлов в VFS кэше, компиляция с -j1000 поставила систему в полностью неработоспособное состояние (Core Duo, 2Gb, DMA для дисков включен :)

В случае подобной компиляции, _только_ если выполняется одна она, разницы практически не должно быть, т.к. по сути выполняются одни и те же операции с учетом накладных планировщика для 1000 задач. Только при этом все остальные задачи затормозятся _значительно_, при определенных нагрузках на VFS/swapd это может стать фатальным.

>sS *** (*) (11.01.2007 17:59:04)

дистр Slamd64-11 ; рабочее и компилируемое ядро - 2.6.19.1 x86_64; шедулер CFQ ; PentiumD 955 (двуядерник, 3.6ГГц, 2*2Мб кеша) ; 4*1Гб DDR2-667 (двухканальный режим) ; чипсет nForce4 Intel SLI Edition ; SATA 150Gb 10000rpm ; make oldconfig ; без форсирования по nice -n ; time:

make -j1 bzImage: real 5m14.138s ; user 4m42.487s ; sys 0m36.114s
make -j2 bzImage: real 2m48.870s ; user 4m44.417s ; sys 0m35.961s
make -j3 bzImage: real 2m48.010s ; user 4m45.373s ; sys 0m36.371s
make -j5 bzImage: real 2m47.450s ; user 4m45.461s ; sys 0m36.732s
make -j10 bzImage: real 2m47.889s ; user 4m45.653s ; sys 0m36.962s
make -j100 bzImage: real 2m46.875s ; user 4m45.496s ; sys 0m36.624s
make -j1000 bzImage: real 2m45.027s ; user 4m.45.353s ; sys 0m36.544s
make -j bzImage: real 3m6.092s ; user 4m46.277s ; sys 0m39.101s

P. S. Блин! А собирать ядро с infinite jobs было прикольно! Как оно взвыло и винтом задергало! :-)

> Гарвардская архитектура. Ага. Есть такое слово. И оно не матерное. Марш в школу, умник фигов.

Я хотел сказать между ОЗУ и контроллером памяти...

>В случае подобной компиляции, _только_ если выполняется одна она, разницы практически не должно быть, т.к. по сути выполняются одни и те же операции с учетом накладных планировщика для 1000 задач.

... разницы между -j4 и -j1000. -j2 и -j1 медленнее.

Если же файлы не в кэше и в зависимости от другой нагрузки ситуация может быть любой от "зависания" системы до обычной работы.

> Ты что серьезно ставишь на сервер с ораклом хксы?

Деточка - проясни для себя раз и навсегда, что комп неззапущеным X-сервером отличается от компа с неустановленым X-сервером тольк количеством файлов.

> Умник, какое отношение имеет декодер команд, конвейер и устройство кеша к КОНТРОЛЛЕРУ ПАМЯТИ? Где мля 2 отдельных шины, идущих к модулям памяти - одна для команд вторая для данных? Одновременно по шине может передаваться объем информации, соответсвующий ее разрядности, если шина на 64 бита, а 64 бита данных не выровнены, то данные потребуется пересылать по шине по частям, за два цикла.

Дружочек, да не извлекает современный процессор команды по одному из памяти, как было 20 лет назад. Независимо от размера нужной информации, длина запроса к контроллеру памяти ВСЕГДА равна размеру кеш-линейки кеша L2 либо L1 - 64 или 128 БАЙТ. И это ВСЕГДА выровненный участок. Окей ?

> заметь не было сказано ни слова про архитектуру кеш-памяти с отдельным кешем для данных и инструкций(либо uops).

А вот это уже другая песня. Далее из кеша L2 данные рассортировываются по кешам L1 данных и команд. НО ! Кеш-память команд заполняется через дешифратор команд !!! Исполнительные устройства процессора исполняют код ТОЛЬКО из кеша команд, а в этом кеше уже не x86 код, а RISC код, только который и может ядро. Во что именно превращается код после обработки дешифратором команд - могут сказать очень немногие. Но я тебя уверяю, спец ты фигов, там всё либо выровнено либо ещё что, но это сделано максимально оптимально вне зависимости от кода x86, который был.

>Ага, сферический конь в ваккуме - при небольшой нагрузке (дисковые операции) на тестовую машину и полном отсутствии файлов в VFS кэше, компиляция с -j1000 поставила систему в полностью неработоспособное состояние (Core Duo, 2Gb, DMA для дисков включен :)

Это у вас так VM настроена ;)

В этом как раз отличие настройки для десктопа от настройки для узла кластера

У меня безболезненно до -j4000 можно на одном узле компилять.

Если превысить хардлимит make просто тупо встанет но реакция системы практически не изменится. И это при LA~300.

> Это у вас так VM настроена ;)

А как её надо настраивать?

>>Ага, сферический конь в ваккуме - при небольшой нагрузке (дисковые операции) на тестовую машину и полном отсутствии файлов в VFS кэше, компиляция с -j1000 поставила систему в полностью неработоспособное состояние (Core Duo, 2Gb, DMA для дисков включен :)

>Это у вас так VM настроена ;)

>В этом как раз отличие настройки для десктопа от настройки для узла кластера

Согласен, но при любых настройках VM такой лимит существует - а по достижении момента, когда количество параллельно работающих процессов make превысит количество необходимой работы, начнутся ощутимые потери в производительности по сравнению с -j2-4-8 aka количество процессоров, умноженное на 2-4.

>sS *** (*) (11.01.2007 21:31:01)

> Согласен, но при любых настройках VM такой лимит существует

И чё? Лимиты на всё существуют, а людям (по крайней мере, некоторым) специально дан МОСК, чтобы эти лимиты не превышать.

>> Это у вас так VM настроена ;) > А как её надо настраивать?

В зависимости от того чем система будет заниматься.

В LKML на эту тему сломана куча копий ;) ну например http://kerneltrap.org/node/3000

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

Так какие возражения по существу у вас к вышесказанному?

Re: от frame 11.01.2007 13:14:51
Re:
> речь про выравнивание кода, а не данных

Код это тоже данные, которые передаются из ОЗУ по шине данных.

sysenter (*) (11.01.2007 14:06:35)

Есть возражения, что и данные и код с точки зрения контроллера памяти
не различаются? Или к чему вы здесь раскидываете пальцы про Гарвардскую
архитектуру и т.д.?

> Независимо от размера нужной информации, длина запроса к
контроллеру памяти ВСЕГДА равна размеру кеш-линейки кеша L2 либо L1 -
64 или 128 БАЙТ. И это ВСЕГДА выровненный участок. Окей ?

Окей. Вот только почему при этом слово данных(dw,dd,dq) либо
инструкция не могут находиться на границе в 64 или 128байт, чтобы
контроллеру памяти пришлось делать два запроса?

> А вот это уже другая песня. Далее из кеша L2 данные
рассортировываются по кешам L1 данных и команд. НО ! Кеш-память
команд заполняется через дешифратор команд !!! Исполнительные
устройства процессора исполняют код ТОЛЬКО из кеша команд, а в этом
кеше уже не x86 код, а RISC код, только который и может ядро.

Очень было приятно выслушать ликбез по архитектуре Netburst, которую,
кстати Intel отправил на помойку.

> Во что именно превращается код после обработки дешифратором команд
- могут сказать очень немногие. Но я тебя уверяю, спец ты фигов, там
всё либо выровнено либо ещё что, но это сделано максимально
оптимально вне зависимости от кода x86, который был.

Только фиговые спецы уверяют в том, чего сами не знают. ;) Если бы
это было так, то оптимизация x86 кода под Netburst была бы
невозможна, да и ненужна - процессор сам бы молотил код максимально
эффективно.

> Есть возражения, что и данные и код с точки зрения контроллера памяти не различаются? Или к чему вы здесь раскидываете пальцы про Гарвардскую архитектуру и т.д.?

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

> Окей. Вот только почему при этом слово данных(dw,dd,dq) либо инструкция не могут находиться на границе в 64 или 128байт, чтобы контроллеру памяти пришлось делать два запроса?

Теоретичеки - могут. Практически - это надо так очень конкретно постараться, специально делая гадкий код для демонстрации. И то интересно, насколько это опустит протзводительность. Не думаю, что ниже единиц процентов. См. реальные тесты выше - на реальном коде ключи выравнивания не дают ВООБЩЕ НИЧЕГО на современных x86 процессорах.

> Очень было приятно выслушать ликбез по архитектуре Netburst, которую, кстати Intel отправил на помойку.

Во-первых, ещё пока не отправили, весь low- и middle- end у Intel сейчас Netburst. А это большинство продаж. Intel продаёт 76% процессоров => большинство имеющихся сейчас в эксплутации процессоров - Netburst, хочется это кому-то или нет. Во-вторых, все остальные x86 процессоры от NetBurst отличаются не принципиально, всё равно они исполняют RISC код, а не x86. Ещё раз см. выше - ключи mallign не дают ничего, вне зависмости от Ваших потуг что-то доказать.

> Если бы это было так, то оптимизация x86 кода под Netburst была бы невозможна, да и ненужна - процессор сам бы молотил код максимально эффективно.

Слишком наивно требовать от дешифратора команд оптимизировать код. С этим даже хороший компилятор не всегда справляется. Но то, что он выравнивает - это даже не вопроос. Хотябы потому, что RISC инструкция всегда выровнена.

>См. реальные тесты выше - на реальном коде ключи выравнивания не дают ВООБЩЕ НИЧЕГО на современных x86 процессорах

http://www.wasm.ru/forum/viewtopic.php?pid=135431#p135431

И вообще, это тёплая зима провоцирует избыточную активность =)

И неудачный я выбрал пример ранее, т.к. процессоры АМД-K7 известны своей "всеядностью" (параметры выравнивания по умолчанию в GCC для них меньше, чем для "интеловских" процессоров - если оценивать размеры бинарников и смотреть директивы в asm-листингах), код bzip2 полностью умещается в L1-кэше моего процессора. Лично мне кажется, если бы выравнивание было бы АБСОЛЮТНО бесполезным - ответственные люди его бы просто убрали из ядра и сэкномили заодно несколько десятков килобайт памяти, что для кэша в определённых местах весьма критично.

> Лично мне кажется, если бы выравнивание было бы АБСОЛЮТНО бесполезным - ответственные люди его бы просто убрали из ядра и сэкномили заодно несколько десятков килобайт памяти, что для кэша в определённых местах весьма критично.

На некоторых старых процессорах выравниване может быть полезно. Скорее всего, это когда-то сделали, теперь не трогают. Потому что уже и в манах пропиано и все привыкли. Атавизмов полно везде.

> И неудачный я выбрал пример ранее,

Ну, покажИте удачный. Очень интересно будет на это посмотреть.

> http://www.wasm.ru/forum/viewtopic.php?pid=135431#p135431

Там по сути повторение того, что написано сдесь. И ни одного примера, где выравнивание даёт прирост производительности.

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

>Во-вторых, на современных PC платформах, выравнивание не даёт _НИЧЕГО_. Ну вообще ничего. Даже иногда не невыровненные данные быстрее работают. Учите матчасть, дружочек.

> Слишком наивно требовать от дешифратора команд оптимизировать код. С этим даже хороший компилятор не всегда справляется. Но то, что он выравнивает - это даже не вопроос. Хотябы потому, что RISC инструкция всегда выровнена.

Что скажете насчет:

3.6.3 Alignment
...

Misaligned data access can incur significant performance penalties. This is particu-
larly true for cache line splits. The size of a cache line is 64 bytes in the Pentium 4
and other recent Intel processors, including processors based on Intel Core microar
chitecture.
An access to data unaligned on 64-byte boundary leads to two memory accesses and
requires several µops to be executed (instead of one). Accesses that span 64-byte
boundaries are likely to incur a large performance penalty, the cost of each stall
generally are greater on machines with longer pipelines.
Double-precision floating-point operands that are eight-byte aligned have better
performance than operands that are not eight-byte aligned, since they are less likely
to incur penalties for cache and MOB splits. Floating-point operation on a memory
operands require that the operand be loaded from memory. This incurs an additional
µop, which can have a minor negative impact on front end bandwidth. Additionally,
memory operands may cause a data cache miss, causing a penalty.
Assembly/Compiler Coding Rule 45. (H impact, H generality) Align data on
natural operand size address boundaries. If the data will be accessed with vector
instruction loads and stores, align the data on 16-byte boundaries.
For best performance, align data as follows:
• Align 8-bit data at any address.
• Align 16-bit data to be contained within an aligned 4-byte word.
• Align 32-bit data so that its base address is a multiple of four.
• Align 64-bit data so that its base address is a multiple of eight.
• Align 80-bit data so that its base address is a multiple of sixteen.
• Align 128-bit data so that its base address is a multiple of sixteen.
A 64-byte or greater data structure or array should be aligned so that its base
address is a multiple of 64. Sorting data in decreasing size order is one heuristic for
assisting with natural alignment. As long as 16-byte boundaries (and cache lines) are
never crossed, natural alignment is not strictly necessary (though it is an easy way
to enforce this).
Example 3-28 shows the type of code that can cause a cache line split. The code
loads the addresses of two DWORD arrays. 029E70FEH is not a 4-byte-aligned
address, so a 4-byte access at this address will get 2 bytes from the cache line this
address is contained in, and 2 bytes from the cache line that starts at 029E700H. On
processors with 64-byte cache lines, a similar cache line split will occur every 8 iter-
ations.

...

Alignment of code is less important for processors based on Intel NetBurst microar-
chitecture. Alignment of branch targets to maximize bandwidth of fetching cached
instructions is an issue only when not executing out of the trace cache.
Alignment of code can be an issue for the Pentium M, Intel Core Duo and Intel Core 2
Duo processors. Alignment of branch targets will improve decoder throughput.


3.4.1.5 Code Alignment
Careful arrangement of code can enhance cache and memory locality. Likely
sequences of basic blocks should be laid out contiguously in memory. This may
involve removing unlikely code, such as code to handle error conditions, from the
sequence. See Section 3.7, “Prefetching,” on optimizing the instruction prefetcher.

Assembly/Compiler Coding Rule 12. (M impact, H generality) All branch
targets should be 16-byte aligned.

...

Table 3-1. Store Forwarding Restrictions of Processors
Based on Intel Core Microarchitecture
Width of Store
Store Store Load Alignment Width of Forwarding
Alignment (bits) (byte) Load (bits) Restriction
To Natural size 16 word aligned 8, 16 not stalled
To Natural size 16 not word aligned 8 stalled
To Natural size 32 dword aligned 8, 32 not stalled
To Natural size 32 not dword aligned 8 stalled
To Natural size 32 word aligned 16 not stalled
To Natural size 32 not word aligned 16 stalled
To Natural size 64 qword aligned 8, 16, 64 not stalled

... и т.д.

(c) Intel 64 and IA-32 Architectures Optimisation Reference Manual

Так что не все просто на самом деле с выравниванием.

Дык это и ежу понятно.
Тока, видимо, господин wa по уровню своего интеллекта даже до ежей не дотягивает. А потому на протяжении вот уже скольких страниц звездит бред.

╔═[■]════════════════════════[ Hello All! ]═══════─────────--─--─-

Эх! Хорошо быть членом! Растешь - растешь, стал взрослым, а потом раз - и опять маленький!

╚═[ Andrew Usachov ]═══════════════[ 23 фев 2006, 13:41 ]══───-─-

--- * Origin: U$A station (2:5100/87)

Одного раввина всегда терзало искушение отведать свининки. И вот однажды он отьехал от города подальше и в какой-то придорожной забегаловке заказал большое блюдо из свинины. И вот сидит он, ждет заказ и вдруг видит, что в кафе заходит главный раввин его синагоги. А тут и официант приносит и ставит на стол такого румяного жареного поросеночка с зеленью и яблочком во рту. Ну начальник ессно выпучил зенки на это дело, а раввин всплеснул руками и сказал: - Ну надо же, как они тут сервируют яблоки....!!!!