LINUX.ORG.RU

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


0

0

Greg Kroah-Hartman выпустил книгу "Linux kernel in a nutshell", в которой он описывает процесс конфигурации, сборки и установки ядра Линукс. Книга описывает большинство опций конфигурации ядра (изначально планировалось описать их все, но тогда размер книги превысил бы 1000 страниц), автор особенно гордится главой, описывающей процесс выбора опций ядра для нетипичной конфигурации аппаратного обеспечения.

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

Книга доступна как в печатном виде, так и в форматах pdf и DocBook. Впервые в истории так же доступна полная история написания книги в репозитории git (http://www.kernel.org/git/?p=linux/ke...).

Купить на Amazon.com: http://www.amazon.com/Linux-Kernel-Nu...

>>> Подробности

★★

Проверено: Shaman007 ()

Ответ на: комментарий от R00T

> Ну и включение оптимизаций. Типа "-O3 -march=prescott -mfpmath=sse -msse3 -pipe -s" в ядре

Блииин... Ну тебе же по-русски говорят - в ядре плавающая точка НЕ ИСПОЛЬЗУЕТСЯ. Так что все твои "-mfpmath=sse -msse3" бесполезны.

А это ничего, что -O3 от -O2 значимо отличается только в -finline-function (который увеличивает код при незначительной эффективности, особенно в сочетании с Register arguments), -funswitch-loop - эффект от которого в плане производительности заметен только для длинных (больших по объему вложеных операций) циклов? В ядре, кстати, большинство наиболее частых циклов короткие...

no-dashi ★★★★★
()
Ответ на: комментарий от anonymous

> Кстати, скачать DVD нельзя, тока на 5 cd. Очень весело прыгать вокруг сервера, сначала первый диск, потом все остальные, потом снова первый...

"Млять, а мужики то не знают" (c) реклама

И какже это я который год из 5CD с федорой делаю один DVD? Наверное потому, что "асилил" гугль на предмет mkdvdiso.sh?

no-dashi ★★★★★
()
Ответ на: комментарий от anonymous

>И не дай бог сервер без иксов поставишь, оракл потом не встанет, ему иксы нужны.

Это пипец...нет это детский сад :)
Пожалуйста убей себя об стену чтобы не портить породу оракл-администраторов.

anonymous
()

Поддерживаю ROOT-а в том:

1. Ядро должно быть собрано только с необходимыми опциями - по минимуму - монолит (сильно рекомендуется). Ядро собираю только по необходимости. Делается легко:

a) cd /usr/src/<linux kernel src>
b) make mrproper
c)
zcat /proc/config.gz > .config
или
mount /boot; cp /boot/config .config
(кому как нравится)
d) make oldconfig
e) (mount /boot если ещё не был примонтирован) make && make install (&& make modules_install)

make install всё сделает за вас: меняет ссылки vmlinuz.old на старое ядро, vmlinuz на новое (соответственно, то же самое и для config), вам достаточно только иметь записи в загрузчике для двух ядер; на новое и на старое:
kernel (hd0,0)/vmlinuz и kernel (hd0,0)/vmlinuz.old и никаких копирований bzImage и тому подобное.

По возможности, ядро тоже должно оптимизироваться (семафоры, лимиты, макс кол-во открываемых файлов и т.д.). (Ну и Makefile ядра можно поправить (добавить march, funroll-loops)).

2. Ключи оптимизации должны применяться. В моём случае:

Для десктопа: C(XX)FLAGS="-march=<arch> -O3 -mfpmath=sse -ftracer -fforce-addr -fomit-frame-pointer -funroll-loops -fprefetch-loop-arrays -maccumulate-outgoing-args -pipe"

Для сервера: то же самое, что и выше, только вместо ключа "O3" идёт "O2".

Примечание: mfpmath=sse используется только на тех процессорах, где это поддерживается.

3. Сервисы должны иметь только минимально необходимую функциональность. То же самое касается и самого сервера.

dotcoder ★★★★★
()
Ответ на: комментарий от dotcoder

Угу мы то лохи ядро новое ставим apt-get install kernel-image-std-smp#<номер-версии> ну или rt версию, что по выбору охота. Видно зря жизнь прожили...

anonymous
()
Ответ на: комментарий от anonymous

>Угу мы то лохи ядро новое ставим apt-get install kernel-image-std-smp#<номер-версии> ну или rt версию, что по выбору охота. Видно зря жизнь прожили...

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

dotcoder ★★★★★
()
Ответ на: комментарий от wa

Вы доктор? А диплом соответствующего университета покажете? Если вы чего-то ни разу не встречали это не значит, что этого нет.

cobold ★★★★★
()
Ответ на: комментарий от dotcoder

> Ядро должно быть собрано только с необходимыми опциями - по минимуму - монолит (сильно рекомендуется)

Монолитное ядро настоятельно НЕ рекомендуется применять в системах общего назначения.

> make && make install (&& make modules_install)

Клиника. Ты в курсе, что очень часто такая последовательность дает гарнтированно негрузящееся ядро?

> По возможности, ядро тоже должно оптимизироваться (семафоры, лимиты, макс кол-во открываемых файлов и т.д.).

А потом у вас будет "почему-то" валиться то почтовик, то браузер, то апач, то mysql. А какой-нибудь софт вообще просто будет трапиться не говоря ни слова. И вы не сможете повторить ситуацию на другом компе - ядра ведь разные.

no-dashi ★★★★★
()
Ответ на: комментарий от anonymous

>>И не дай бог сервер без иксов поставишь, оракл потом не встанет, ему иксы нужны. >Это пипец...нет это детский сад :)

В чем детский сад?

Цитирую no-dashi:

Ораклу как таковому жаба вообще не нужна, но его инсталлер и утилиты (OEM например, network assistant, db assistant и прочие) используют оракловый тулкит aurora, который использует awt, который в свою очередь ходит на libX11.so.

anonymous
()
Ответ на: комментарий от anonymous

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

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

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

>> make && make install (&& make modules_install)

>Клиника. Ты в курсе, что очень часто такая последовательность дает гарнтированно негрузящееся ядро?

У кого не даёт, у меня всегда всё нормально грузится - при чём, _гарантировано_. Так как, я знаю, что включать, а что не включать в ядре. Надо просто знать свою систему и опции настройки ядра.

>> По возможности, ядро тоже должно оптимизироваться (семафоры, лимиты, макс кол-во открываемых файлов и т.д.).

>А потом у вас будет "почему-то" валиться то почтовик, то браузер, то апач, то mysql. А какой-нибудь софт вообще просто будет трапиться не говоря ни слова. И вы не сможете повторить ситуацию на другом компе - ядра ведь разные.

Опять-таки это не такой уж rocket science - надо просто уметь и знать. Базовых параметров тюнинга не так уж и много в ядре: 5-6 опций в самом ядре, и то опции лишь повышающие значения по-умолчанию. И поверьте, за 7 лет у меня не было такого, чтобы валился то почтовик, то апач, то mysql (и это всё даже без наличия супервизора сервисов-демонов). Наверное, это из-за того, что я хорошо знаю систему и знаю, что где как "подкрутить" и подтюнить, а не как некоторые, которые не изучив вопроса, не прочитав документацию лезут в бой "методом тыка".

Вердикт: Если человек не знает вопроса, то ему незачем лезть туда, что он не знает.

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

dotcoder ★★★★★
()
Ответ на: комментарий от no-dashi

И ещё, заметьте, уважаемый no-dashi, что всё, что я говорю описано в многочисленных документах, статьях, книгах, best practices, есть чему учиться.

dotcoder ★★★★★
()

dotcoder@dotcoder ~ $ cat /var/tmp/0100-increase-kernel-2.6-defaults.patch
diff -Nurp old/drivers/block/loop.c new/drivers/block/loop.c
--- old/drivers/block/loop.c    2004-10-20 13:00:58.000000000 +0600
+++ new/drivers/block/loop.c    2004-10-20 13:47:08.000000000 +0600
@@ -70,7 +70,7 @@

 #include <asm/uaccess.h>

-static int max_loop = 8;
+static int max_loop = 32;
 static struct loop_device *loop_dev;
 static struct gendisk **disks;

diff -Nurp old/include/linux/limits.h new/include/linux/limits.h
--- old/include/linux/limits.h  2004-10-20 13:00:58.000000000 +0600
+++ new/include/linux/limits.h  2004-10-20 13:50:28.000000000 +0600
@@ -1,12 +1,12 @@
 #ifndef _LINUX_LIMITS_H
 #define _LINUX_LIMITS_H

-#define NR_OPEN                1024
+#define NR_OPEN                8192

 #define NGROUPS_MAX    65536   /* supplemental group IDs are available */
 #define ARG_MAX       131072   /* # bytes of args + environ for exec() */
 #define CHILD_MAX        999    /* no limit :-) */
-#define OPEN_MAX         256   /* # open files a process may have */
+#define OPEN_MAX        8192   /* # open files a process may have */
 #define LINK_MAX         127   /* # links a file may have */
 #define MAX_CANON        255   /* size of the canonical input queue */
 #define MAX_INPUT        255   /* size of the type-ahead buffer */
diff -Nurp old/include/linux/msg.h new/include/linux/msg.h
--- old/include/linux/msg.h     2004-10-20 13:00:58.000000000 +0600
+++ new/include/linux/msg.h     2004-10-20 13:49:12.000000000 +0600
@@ -50,7 +50,7 @@ struct msginfo {
        unsigned short  msgseg;
 };

-#define MSGMNI    16   /* <= IPCMNI */     /* max # of msg queue identifiers */
+#define MSGMNI   512   /* <= IPCMNI */     /* max # of msg queue identifiers */
 #define MSGMAX  8192   /* <= INT_MAX */   /* max size of message (bytes) */
 #define MSGMNB 16384   /* <= INT_MAX */   /* default max size of a message queue */

diff -Nurp old/include/linux/posix_types.h new/include/linux/posix_types.h
--- old/include/linux/posix_types.h     2004-10-20 13:00:58.000000000 +0600
+++ new/include/linux/posix_types.h     2004-10-20 13:50:13.000000000 +0600
@@ -22,7 +22,7 @@
 #define __NFDBITS      (8 * sizeof(unsigned long))

 #undef __FD_SETSIZE
-#define __FD_SETSIZE   1024
+#define __FD_SETSIZE   8192

 #undef __FDSET_LONGS
 #define __FDSET_LONGS  (__FD_SETSIZE/__NFDBITS)
diff -Nurp old/include/linux/sem.h new/include/linux/sem.h
--- old/include/linux/sem.h     2004-10-20 13:00:58.000000000 +0600
+++ new/include/linux/sem.h     2004-10-20 13:50:01.000000000 +0600
@@ -64,7 +64,7 @@ struct  seminfo {
        int semaem;
 };

-#define SEMMNI  128             /* <= IPCMNI  max # of semaphore identifiers */
+#define SEMMNI  1024            /* <= IPCMNI  max # of semaphore identifiers */
 #define SEMMSL  250             /* <= 8 000 max num of semaphores per id */
 #define SEMMNS  (SEMMNI*SEMMSL) /* <= INT_MAX max # of semaphores in system */
 #define SEMOPM  32             /* <= 1 000 max num of ops per semop call */
dotcoder@dotcoder ~ $                                                          

dotcoder ★★★★★
()
Ответ на: комментарий от dotcoder

Это простой пример повышения значений по-умолчанию, а ведь ещё есть /etc/sysctl.conf ;) есть /etc/security/limits.conf :) есть RBAC, MAC ACLs.

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

dotcoder ★★★★★
()
Ответ на: комментарий от no-dashi

>А потом у вас будет "почему-то" валиться то почтовик, то браузер, то апач, то mysql.

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

dotcoder ★★★★★
()
Ответ на: комментарий от dotcoder

Т е вы считаете что весь этот геморой с правкой например кол-ва loop devices стоит и поддержкой секюрити фиксов стоит того? Мне кажется проще задать один раз в конфиге параметр модуля и забыть об этом. 8-)

Дальше уже забота секюрити тим любимого дистрибутива 8-)

villain
()
Ответ на: комментарий от dotcoder

>dotcoder@dotcoder ~ $ cat /var/tmp/0100-increase-kernel-2.6-defaults.patch
diff -Nurp old/drivers/block/loop.c new/drivers/block/loop.c...

это уже клиника.

специально для ROOT и его замечанию о initrd

$ ls -la /boot/*2.6.18-3*
-rw-r--r-- 1 root root  720074 Dec 11 04:27 /boot/System.map-2.6.18-3-686
-rw-r--r-- 1 root root   71331 Dec 10 21:50 /boot/config-2.6.18-3-686
-rw------- 1 root root 1154084 Dec 11 17:13 /boot/initrd.img-2.6.18-3-686
-rw-r--r-- 1 root root 1259885 Dec 11 04:27 /boot/vmlinuz-2.6.18-3-686

anonymous
()
Ответ на: комментарий от villain

>Т е вы считаете что весь этот геморой с правкой например кол-ва loop devices стоит и поддержкой секюрити фиксов стоит того? Мне кажется проще задать один раз в конфиге параметр модуля и забыть об этом. 8-)

Ядро обновляется только при необходимости, если новая версия ядра исправляет критические ошибки.

dotcoder ★★★★★
()
Ответ на: комментарий от anonymous

>>dotcoder@dotcoder ~ $ cat /var/tmp/0100-increase-kernel-2.6-defaults.patch diff -Nurp old/drivers/block/loop.c new/drivers/block/loop.c...

>это уже клиника.

Обоснуйте! Вы хоть знаете, за что каждый параметр отвечает? Или вам достаточно, чтобы было C:\, %Windows%, %ProgramFiles%? А про такие вещи как sysctl и всё остальное и не слышали?

dotcoder ★★★★★
()
Ответ на: комментарий от dotcoder

что дает повышение лимитов на откр. файлы, если этот лимит всё равно никогда не достигается? Или вы про что-то другое?

Давно интересовался влиянием sysctl на производительность системы, да всё так нормального описания именно вляния (а не назначение конкретной опции) не нашел, может вы просветите?

redbaron ★★
()
Ответ на: комментарий от dotcoder

Эх, точкокодер...
Кажется тебе пора идти читать доку, причем срочно:

> -static int max_loop = 8;
> +static int max_loop = 32;

Это регулируется на ходу параметром модуля
Но "кулхацкеры" вкомпиляют loop статично и вынуждены
ребутиться для смены этого параметра. Кстати даже при
статической компиляции оно меняется путем указания в
загрузчике - и пересобирать для ЭТОГО ядро не нужно.

> -#define MSGMNI    16
> +#define MSGMNI   512

Это меняется через sysctl

> -#define OPEN_MAX         256
> +#define OPEN_MAX        8192

Это значение вообще для compatibility reason, вот
тебе маленький тест на ядре 2.6.19, чистой "ванилле":

[root@viking ~]# ulimit -n 32768
[root@viking ~]# cat test.c 
#include <stdio.h>
int main() {
    int i = 0;
    while (fopen("/dev/null","r")) i++;
    /* stdin, stdout, stderr is also opened files */
    printf("%d\n",3+i);
    return 0;
}
[root@viking ~]# make test
cc     test.c   -o test
[root@viking ~]# ./test 
32768

> -#define __FD_SETSIZE   1024
> +#define __FD_SETSIZE   8192

Ваша glibc об этом уже знает?

no-dashi ★★★★★
()
Ответ на: комментарий от dotcoder

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

anonymous
()
Ответ на: комментарий от redbaron

>Давно интересовался влиянием sysctl на производительность системы, да всё так нормального описания именно вляния (а не назначение конкретной опции) не нашел, может вы просветите?

Да, конечно: /usr/src/linux/Documentation/sysctl/

Начните с PostgreSQL, например, как влияет значение shared buffers/shared memory на производительность. Ну и найдите связь с выше-указанным конфигом с семафорами.

С понятием FD (file descriptors, параметр OPEN_MAX (NR_OPEN) зависит от FD_SETSIZE), а именно с нехваткой оных вы можете столкнутся на многих приложениях, которым одновременно нужен доступ на множество файлов (например, Squid).

Тюнинг сетевых параметров. Примеров много.

dotcoder ★★★★★
()
Ответ на: комментарий от scholz

Хз, просто есть время на эту фигню, т.к. врядли мнение оппонента окажется для кого-то решающим. Мне ядро впервые (v2.2) пришлось компилить, чтобы нужное мне железо завелось и как с этим у других - мне всё равно. Миллионы баков можно зарабатывать даже не зная всего этого =)

frame ★★★
()
Ответ на: комментарий от villain

>Т е на вопрос не ответили, ибо секюрити фиксы именно это и делают 8-) Стоит или нет весь геморой того.

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

dotcoder ★★★★★
()
Ответ на: комментарий от frame

> какой смысл по умолчанию для i686 это (align) включать - мне непонятно :\

На Сайриксе M2 или PPro оно может и поможет. Может даже и на втором пеньке поможет. На первых пеньках точно помогало. Это всё уже такое старьё, что тяжело такие машины найти и посмотреть. Даже в книгах уже про такие машины уже не пишут.

wa
()
Ответ на: комментарий от scholz

> Что-то не совсем понятно... С чего вообще разведена дискуссия? Есть те, кому ядро компилить нет ни надобности, ни желания. Или тут есть те, кто сильно переживает за потери производительности у человечества?

Всё с точностью до наоборот. Подняли несусветный визг как раз те, кто сам ядро не компилят. Им же, пилять, до всех надо Правду донести. Они же не могут спать спокойно, пока кто-то занимается таким непотребством - сам (!!) собирает ядро, богохульник.

anonymous
()
Ответ на: комментарий от R00T

> Этот странный субъект wa, подписывающийся именем прогера Glukalka'и, не соизволил даже man gcc прочитать...

lenin развёлся с krupskaya и сменил фамилию????

anonymous
()
Ответ на: комментарий от no-dashi

>Эх, точкокодер... >Кажется тебе пора идти читать доку, причем срочно:

>> -static int max_loop = 8; >> +static int max_loop = 32;

>Это регулируется на ходу параметром модуля >Но "кулхацкеры" вкомпиляют loop статично и вынуждены >ребутиться для смены этого параметра. Кстати даже при >статической компиляции оно меняется путем указания в >загрузчике - и пересобирать для ЭТОГО ядро не нужно.

Верно, этот параметр можно задавать путём указания в загрузчике. Я выше писал про системы с поддержкой 7 лет - сила привычки, понимаете ли. А эта фича доступна с 2.4.х.

>> -#define MSGMNI 16 >> +#define MSGMNI 512

>Это меняется через sysctl

Верно, можно также менять через sysctl.

>> -#define OPEN_MAX 256 >> +#define OPEN_MAX 8192

>Это значение вообще для compatibility reason >> -#define __FD_SETSIZE 1024 >> +#define __FD_SETSIZE 8192

>Ваша glibc об этом уже знает?

http://www.gnu.org/software/libc/FAQ.html#s-2.25

2.25. I need lots of open files. What do I have to do? {AJ} This is at first a kernel issue. The kernel defines limits with OPEN_MAX the number of simultaneous open files and with FD_SETSIZE the number of used file descriptors. You need to change these values in your kernel and recompile the kernel so that the kernel allows more open files. You don't necessarily need to recompile the GNU C library since the only place where OPEN_MAX and FD_SETSIZE is really needed in the library itself is the size of fd_set which is used by select.

The GNU C library is now select free. This means it internally has no limits imposed by the `fd_set' type. Instead all places where the functionality is needed the `poll' function is used.

If you increase the number of file descriptors in the kernel you don't need to recompile the C library.

{UD} You can always get the maximum number of file descriptors a process is allowed to have open at any time using

number = sysconf (_SC_OPEN_MAX);

This will work even if the kernel limits change.

dotcoder ★★★★★
()

И ещё, очень красноречиво и популярно (в тему про тюнинг и оптимизацию):

/usr/src/linux/Documentation/sysctl/README:

-snip-

Well, this documentation is written because some people either don't know they need to tweak something, or because they don't have the time or knowledge to read the source code.

Furthermore, the programmers who built sysctl have built it to be actually used, not just for the fun of programming it :-)

-snip-

dotcoder ★★★★★
()
Ответ на: комментарий от dotcoder

> the only place where OPEN_MAX and FD_SETSIZE is really needed in the library itself is the size of fd_set which is used by select.

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

Править ядро для этого опять таки не нужно, поскольку в момент сборки юзерспейсовых приложение эти константы берутся не из исходников ядра, а их того, что называют glibc-kernel-headers - то есть тех ашек, которые лежат в /usr/include/linux

Упс?

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

Не, я конечно понимаю, что вы могли устроить что-то вроде { cd /usr/include ; mv linux linux-old ; ln -s /usr/src/linux-2.6/include/linux . ; } и тому подобное, но тогда что же у вас за дистрибутив? Только не говорите что "слака"...

no-dashi ★★★★★
()
Ответ на: комментарий от anonymous

> Они же не могут спать спокойно, пока кто-то занимается таким непотребством - сам (!!) собирает ядро

Увянь. В этом треде я вроде как отношусь как раз к таким - но если ты причитаешься внимательно, то поймешь что у меня таки самосбор, и даже не из дистрибутивных исходников. Речь давно идет о том, что пересобирать ядро "под машину" на самом деле не имеет смысла.

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

>Править ядро для этого опять таки не нужно, поскольку в момент сборки юзерспейсовых приложение эти константы берутся не из исходников ядра, а их того, что называют glibc-kernel-headers - то есть тех ашек, которые лежат в /usr/include/linux

Ну так ведь лимиты-то hard-limited в собранном ядре, в контексте ядра.

dotcoder ★★★★★
()
Ответ на: комментарий от wa

>Даже в книгах уже про такие машины уже не пишут.

тут есть немного: http://www.agner.org/optimize/

"Some processors fetch instructions in aligned 16-byte blocks. It can be advantageous to align critical loop entries and subroutine entries by 16 in order to minimize the number of 16-byte boundaries in the code."

Видимо в userspace-приложениях толку от этого нет особого

frame ★★★
()
Ответ на: комментарий от no-dashi

>Упс?

прочитайте ещё раз:

The kernel defines limits with OPEN_MAX the number of simultaneous open files and with FD_SETSIZE the number of used file descriptors. You _need_ to change these values in your kernel and _recompile_ the kernel so that the kernel _allows_ more open files.

dotcoder ★★★★★
()
Ответ на: комментарий от szh

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

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

anonymous
()
Ответ на: комментарий от sS

>>запустить компиляцию ядра на x86_64 (с практически неограниченной "виртуальной" памятью) с -j1000.

>с 1000 легко даже на x86 ;) Ну будет LA 200 ну и шут с ним.

>Для типичных современных машин хардлимит примерно на порядок больше

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

>sS *** (*) (10.01.2007 17:49:35)

rtc ★★
() автор топика
Ответ на: комментарий от frame

> какой смысл по умолчанию для i686 это (align) включать - мне непонятно :\

А какая шина данных у всех i686 процессоров начиная с PPro вы в курсе? 64-битная. За один цикл из памяти можно считать 8 байт, если данные невыровнены, то те же самые 8 байт считываются за два цикла...

sysenter
()
Ответ на: комментарий от R00T

>r00t@root:~$ cat /usr/src/soft/kernel/linux-2.6.18/Makefile | grep 'O2' >HOSTCFLAGS = -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer >HOSTCXXFLAGS = -O2 >CFLAGS += -O2 >r00t@root:~$ cat /usr/src/soft/kernel/linux-2.6.18/Makefile | grep 'Os' >CFLAGS += -Os

И дальше - -fno-omit-frame-pointr, если включен CONFIG_FRAME_POINTER, который позволяет работать с внешним отладчиком и добавляет нет, не тормоза, а добавочную отладочную информацию.

>> и дает те самые 30%

>Мда? А у меня 30-50% по отношению к бинарникам MySQL, которые в дефолте с -O3 собираются.

>r00t@root:~/mysql-4.1.21$ cat ./configure | grep "O3" >MAX_C_OPTIMIZE="-O3" >MAX_CXX_OPTIMIZE="-O3"

После пересборки ядра и выкидывания ненужных IDE драйверов - это неправда. Может быть вы включили другой тип preemption, сократили/увеличили количесвто процессоров и т.п. Но не из-за оптимизаций компиляции -Oсколько-угодно.

>R00T # (*) (10.01.2007 17:44:37)

rtc ★★
() автор топика
Ответ на: комментарий от frame

А какая принципиально разница-то? :-) Вопрос-то именно в том, чтобы за минимальное время считать из памяти как можно больше информации.

R00T
()
Ответ на: комментарий от dotcoder

> 1. Ядро должно быть собрано только с необходимыми опциями - по минимуму - монолит (сильно рекомендуется).

Какие преимущества по сравнению с модульным это дает? Потеря гибкости и неуниверсальность монолитного ядра? - Однозначно. Потеря возможности автоматически обновлять ядро? Да, соответсвенно большие затраты на сопровождение. Невозможность загрузки на другом железе монолитного ядра ввиду выхода железа из строя без пересборки ядра? - Однозначно, соответственно увеличение времени простоя. Меньший объем монолитного ядра в ОЗУ, чем у модульного? - Да, на десятки, может сотню килобайт. Увеличение производительности монолитного? - Да где-то на доли процента за счет редких прямых межмодульных вызовов jmp/call в монолите, в отличие от модульного ядра, где межмодульные call/jmp косвенные. Защита от LKM-руткитов у монолитного с отключенной загрузкой модулей? - Нет, т.к. существуют руткиты, патчащие /dev/kmem.

> 3. Сервисы должны иметь только минимально необходимую функциональность. То же самое касается и самого сервера.

С точки зрения безопасности это понять можно. Вот только есть более серьезные средства: SElinux, ASLR, PAX... А что насчет сопровождения самосборов? C любовью конфигурируем и собираем ручками каждый демон, затем проверяем понимает ли он свой старый конфиг и начинаем ловить глюки(если соберется) и пишем багтраки? Процесс обновления не автоматизируется, появляются дополнительные проблмы с этапом сборки. По-хорошему сервер должен быть настроен и далее функционировать в течение срока поддержки версии дистрибутива, получая обновления безопасности, которые не могут создать таких проблем, как новая версия с функциональными изменениями, далее - миграция на поддерживаемую версию. С самосбором это недостижимо.

sysenter
()
Ответ на: комментарий от dotcoder

> You _need_ to change these values in your kernel and _recompile_ the kernel so that the kernel _allows_ more open files.

Уж не знаю где ты это вычитал, но:

1. система и так "allows" процессу значительно больше чем OPEN_FILES.

2. FD_SETSIZE переопределяется в юзерспейсе, и ядро для этого править не надо

no-dashi ★★★★★
()
Ответ на: комментарий от anonymous

>зиждется на святой вере

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

>листрибутив без коммерческой поддержки - несерьезно, т.к. гарантирует лишь надежду в то, что будет дистр будет сопровождаться.

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

P.S. перечитай пункт No warranty в GPL. Софт халявный and opensource and без гарантий, но стоимость TCO для большинства такой расклад сильно сбивает.

szh ★★★★
()
Ответ на: комментарий от dotcoder

>Обоснуйте! Вы хоть знаете, за что каждый параметр отвечает? Или вам достаточно, чтобы было C:\, %Windows%, %ProgramFiles%? А про такие вещи как sysctl и всё остальное и не слышали?

Я знаю, и хочу вас уверить, что это совсем не то, что используется в userspace. Например у вас увеличивается количество открытых файлов с 256 до 8 тысяч - вы серьезно считаете, что на vanilla ядре один процесс не может открыть больше 256 файлов?

>dotcoder *** (*) (11.01.2007 11:05:34)

rtc ★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.