sudo make-kpkg --initrd --revision=1.0 kernel_image
sudo make -j4
위 두 명령어의 속도차이가 많이 나나요?
위 두 명령어의 의미적 차이는 무엇 인가요?
sudo make-kpkg --initrd --revision=1.0 kernel_image
sudo make -j4
위 두 명령어의 속도차이가 많이 나나요?
위 두 명령어의 의미적 차이는 무엇 인가요?
[quote="creatives":p5cbvg5e]sudo make-kpkg --initrd --revision=1.0 kernel_image
sudo make -j4
위 두 명령어의 속도차이가 많이 나나요?
위 두 명령어의 의미적 차이는 무엇 인가요?[/quote:p5cbvg5e]
make-kpkg는 결과물로 deb 파일을 내놓습니다.
dpkg -i kernel.deb 로 설치 가능하고 배포도 쉽죠.
비교적 최근에 나온 커널 패키징 방식입니다.
make -j… 옵션은 결과물로 zImage 또는 bzImage와 vmlinuz를 내놓습니다.
역사깊은 전통 수공예(?)같은거라 커널 이미지와 vmlinuz 등을 /boot에 옮기고 grub를 재설정하고…
여튼 전부 다 수동입니다.
그럼 여기서 -j옵션이란? j == jobs
한번에 몇명이 일을 하게 하겠느냐는 옵션입니다.
본격적으로 쓰이기 시작한 것은 멀티코어 CPU가 나오면서부터로 알고 있습니다. (물론 그 이전에도 쓰이긴 했습니다)
이 옵션을 주게되면 프로세스를 주어진 숫자만큼 생성하여 병렬 컴파일을 진행하게 됩니다.
한마디로 서로 컴파일 할 부분을 나눠서 따로따로 분업을 하는거죠.
저 j 옵션에 붙이는 숫자에 대해서는 다들 의견이 분분한데, 지금와서 대중적으로 받아들여지는건 물리적 코어 + 2 정도입니다.
예를들어 내가 사용하는 CPU가 쿼드코어(4)라면 -j6이 되는 식이죠.
하지만 이건 매우 민감한 주제라 함부로 말하고 다니면 싸움나기 딱 좋습니다 (웃음)
한때 여기저기 유명한 사이트(stackoverflow같은)들에서 돌아다닌 공식도 있긴 합니다.
realnum=cat /proc/cpuinfo | grep cores | wc -l
let bestnum=$realnum+$(printf %.0f echo "$realnum*0.2"|bc
)
make -j echo $bestnum
bzImage
이게 뭔 말인가 하면, 일단 물리코어 개수를 구합니다. (realnum)
그리고 물리코어 * 0.2로 나온 결과를 반올림 합니다. (‘realnum * 0.2’ |bc)
그리고 그 숫자를 -j에 옵션으로 줍니다.
그럼 4코어 CPU라면 4*0.2의 반올림이니 1이 나오죠. 그럼 -j5가 되는겁니다.
하지만 역시나 싸움나기 딱 좋습니다.
정답같은거 없어요 (…)
컴파일 시간은 차이가 꽤 나는 편입니다.
다만, 빌드를 돌리면서 동시에 다른 CPU 로드가 걸리는 작업을 한다면 되려 비효율적이 됩니다.
프로그래머나 해커라는 종자들이 CPU가 노는 꼴을 못보는 인간들이다 보니 CPU 각 코어 100%를 찍으려고 안달복달 하다 만든 옵션이니까요.
그리고 컴퓨터 사양이 높을수록 더 좋은 효과를 보게 되기도 합니다.
그래서 걸리는 시간이 어떠냐고 하면 컴퓨터마다 틀리니 뭐라 못하겠군요.
경험상 커널 컴파일에서라면 짧게는 2~3분, 길게는 10분까지 차이가 나는거 같네요.