1 (16.12.2011 03:44:39 отредактировано redux)

При сборке ядра(дебиановским методом) работает в дебиане:
export CONCURRENCY_LEVEL=2
- но при сборке ядра общим методом это не срабатывает. Почему?

При сборке (не ядер, а большинства других вещей) работает вот это:
export MAKEFLAGS='-j 2'
- причем при сборке ядер общим методом оно не работает,
- второе ядро проца включается только если явно дать
make -j2

Почему так?

ЗЫ: ядер у проца 2.

UPD: Применил export MAKEFLAGS='-j2' на более старом ядре(2.6.22.19),- заработало.То есть тут еще вопрос версии.

2

Лично я добавляю строчку

MAKEFLAGS += -j3

в файл Makefile

3 (04.12.2011 14:09:24 отредактировано redux)

neocrust,
Это хорошо. Не через экспорт или аргумент, а напрямую в Makefile. Запишу, чтоб не забыть.

Но вот почему (бывает) при сборке ядра общим способом через экспорт переменной, фактически тоже самое:
export MAKEFLAGS='-j 2'
не срабатывает?

Какие могут быть для этого механизма причины? Или куда копать?

4 (05.12.2011 00:11:05 отредактировано Battle Coder)

А может быть всё-таки MAKEOPTS?

redux пишет:

Но вот почему (бывает) при сборке ядра общим способом через экспорт переменной, фактически тоже самое:
export MAKEFLAGS='-j 2'
не срабатывает?

Я почему-то думаю, что потому что Makefile попросту переопределяет переменную среду, затирая старое значение.

5

Забыл, блин, важный момент:
Всё, что из указанного не заработало,- было в chroot'е.

6

redux пишет:

neocrust,
Но вот почему (бывает) при сборке ядра общим способом через экспорт переменной, фактически тоже самое:
export MAKEFLAGS='-j 2'
не срабатывает?

Какие могут быть для этого механизма причины? Или куда копать?

Сбои происходят на fork каким-то образом, а синхронизаций там, по-видимому нет.

Can't fork, trying again in 5 seconds at /dev/shm/linux-2.6.35.i686/scripts/recordmcount.pl line 179.
make[2]: *** [drivers/md/dm-table.o] Ошибка 1
make[2]: *** Ожидание завершения заданий...
ccache: FATAL: Failed to fork
make[2]: *** [drivers/md/dm-uevent.o] Ошибка 1
Can't fork, trying again in 5 seconds at /dev/shm/linux-2.6.35.i686/scripts/recordmcount.pl line 179.
Can't fork, trying again in 5 seconds at /dev/shm/linux-2.6.35.i686/scripts/recordmcount.pl line 531
make[2]: scripts/Makefile.build:230: fork: Ресурс временно недоступен

Я уже как-то задавался такими вопросами вот здесь: http://rus-linux net/forum/viewtopic.ph … p;start=10
но ответа не знаю  ac

7

Battle Coder пишет:

Я почему-то думаю, что потому что Makefile попросту переопределяет переменную среду, затирая старое значение.

Ничего подобного: make не переходит от компиляции N процессорами к компиляции 1-м - он просто тупо слетает по ошибке!

8

вообще не в тему...

Olej пишет:

ccache: FATAL: Failed to fork

сбои в ccache происходят. а это уже совершенно особый кактус.

95% процентов проблем находятся между клавиатурой и стулом.

9

И кактус этот лучше вырубить.  wink
Если уж ускоряться, то как-то так - http://en.gentoo-wiki.com/wiki/Speeding … with_tmpfs

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

10

newzenon пишет:

И кактус этот лучше вырубить.  wink
Если уж ускоряться, то как-то так - http://en.gentoo-wiki.com/wiki/Speeding … with_tmpfs

Или просто вот так: Как правильно собирать ядро?.
Но вопрос то о другом: почему так странно ведёт себя make -jN при сборке kernel + почему он себя нормально ведёт при сборке не менее "обстоятельных" пакетов, например, таких как PBX FreeSWITCH, или сборка кросово toolchain для tmbedded вариантов Linux: BuildRoot?

С BuildRoot вообще интереснее (см. напр. Linux для embedded применений), потому как он собирает много целей (например, свежий GCC под выбранную архитектуру: ARM, MIPS, ...) и только одной из таких целей есть сам kernel Linux под эту архитектуру, а общую сборку он ведёт под -jN, только где N он сам себе (не юзер) конфигурит по максимуму! Он что? при сборке ядра как одной из целей, сбрасывает его в -j1?
(некогда мне было с этим разбираться, но это - как затравка, кому интересно станет  wink )

11

Olej пишет:

Ничего подобного: make не переходит от компиляции N процессорами к компиляции 1-м - он просто тупо слетает по ошибке!

Нет у меня другая ситуация,- компиляция не слетает,- идёт до конца. Но одним ядром,- с самого начала, или с самого начала двумя.
Думаю, надо копать в сторону настройки оболочки под chroot.

12 (07.12.2011 16:47:18 отредактировано redux)

newzenon пишет:

И кактус этот лучше вырубить.  wink
Если уж ускоряться, то как-то так - http://en.gentoo-wiki.com/wiki/Speeding … with_tmpfs

newzenon, Спасибо , почитаю.
Сразу скажу tmpfs использую(если не всегода, но бывает. ramfs также ковыряю). Но второе ядро проца, имхо никакой оперативкой не заменить.

13 (07.12.2011 16:43:50 отредактировано redux)

Olej пишет:

Но вопрос то о другом: почему так странно ведёт себя make -jN при сборке kernel

Я как раз написал, что в моем случае вызов make с аргументом работает, в отличие от экспорта переменной.
И именно ситуация под chroot. Думаю,- это критично.

14

Olej, За ссылки спасибо.

15 (09.12.2011 19:45:32 отредактировано redux)

newzenon пишет:

И кактус этот лучше вырубить.  wink
Если уж ускоряться, то как-то так - http://en.gentoo-wiki.com/wiki/Speeding … with_tmpfs

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

Не мультипость! Fat-Zer
Замечание заметил.Виноват- исправлюсь. redux

16 (16.12.2011 15:35:01 отредактировано redux)

В общем, стыдно сказать, но причина кажется была в том, что я в этой команде

redux пишет:

export MAKEFLAGS='-j 2'

временами на автопилоте пробел между j и 2 вводил. :lol:

(И надо же, echo было посмотреть.)