Компиляция всеми ядрами

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

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

Почему так?

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

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

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

MAKEFLAGS += -j3

в файл Makefile

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

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

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

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

redux написал:

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

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

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

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.php?f=9&t=1499&start=10
но ответа не знаю :(

Battle Coder написал:

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

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

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

Olej написал:

ccache: FATAL: Failed to fork

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

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

newzenon написал:

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

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

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

Olej написал:

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

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

newzenon написал:

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

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

Olej написал:

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

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

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

newzenon написал:

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

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

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

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

redux написал:

export MAKEFLAGS='-j 2'

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

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