사용자 정의 구성으로 메인라인 Linux 커널을 컴파일하려고 합니다.이것!
64비트 시스템에서 실행됩니다.
마지막 단계에서 OOM(오류 137)으로 인해 커널 연결이 실패합니다.
[...]
DESCEND objtool
INSTALL libsubcmd_headers
CALL scripts/checksyscalls.sh
LD vmlinux.o
Killed
make[2]: *** [scripts/Makefile.vmlinux_o:61: vmlinux.o] Error 137
make[2]: *** Deleting file 'vmlinux.o'
[...]
ulimit -a
각 프로세스의 메모리는 무제한이라고 가정해 보겠습니다.
둘 다 해봤는데 별 차이 없었 make
어요 make -j1
make -j4
.
clang 대신 gcc를 컴파일러로 사용하면 결과는 동일합니다.
컴파일이 왜 그렇게 많은 메모리를 소비하는지 아는 사람이 있습니까? Linux 개발 비용이 점점 높아지고 있습니다.\
답변1
Linux 개발 비용이 점점 높아지고 있습니다.
항상 이랬던 것 같아요.
32GB RAM은 커널 개발 데스크탑에서 일반적입니다. 그러나 그들 중 일부는 만나기 시작했습니다allesconfig-ed 커널을 구축할 때 매우 유용합니다.
운이 좋았군요... 분명히 allesconfig-ing은 아닙니다... 32G 이상이 필요하지 않을 것입니다... ;-)
그런데 CONFIG_HAVE_OBJTOOL=y
.config 파일의 일부를 읽으면 위에 링크된 토론의 일부로 제출된 패치의 이점을 누릴 수 있습니다.
컴파일이 왜 그렇게 많은 메모리를 소비하는지 아는 사람이 있습니까?
이것을 정확하게 말할 수 있는 사람은 당신뿐일지도 모릅니다. (커널 소스 배포판의 모든 최상위 디렉토리에서 찾을 수 있는 다양한 *.o 파일의 크기를 고려한 후(컴파일이 성공적으로 이루어졌으므로))
귀하가 제공한 정보(kernel.config 파일)를 바탕으로 다음과 같이 추측할 수 있습니다.
A/ 커널의 각 구성 요소는 정적으로 연결됩니다.
(선택한 모든 OPTION_*가 "=y"로 표시되어 있음을 알았기 때문에)
이것 자체에는 문제가 없습니다. 커널에서 모든 것을 빌드해야 할 많은 이유가 있을 것이기 때문입니다. 그러나 링크할 때 확실히 상당히 추가될 것입니다. 이를 위해 필요한 모든 RAM을 함께 제공합니다.
=> 가능하다면 커널 부분을 모듈로 구축하는 것을 고려해야 합니다.
B/많은 CONFIG_디버그설정이 나타납니다. 다시 말하지만, 이것 자체에는 아무런 문제가 없지만 CONFIG_KALLSYMS_*=y를 의미하므로 더 말할 것도 없이 다른 부분을 연결하는 데 필요한 RAM이 크게 늘어날 수 있습니다.
그런데 CONFIG_HZ_100=y 외에도 선택한 디버그 기능을 고려할 때 최적의 대기 시간/성능을 찾고 있지 않다고 가정합니다. => 그렇다면 CONFIG_CC_OPTIMIZE_FOR_SIZE 선택을 고려해 보겠습니다.