여러 가지 커널 팁 #1

여러 가지 커널 팁 #1

글쓴이: Dave Jones (dave@ext2.net)
옮긴이: 임종균 (hermes44@secsm.org)
원문: http://ext2.linuxberg.com/99/05/kernel/052999-kernel3.shtml

내게는 커널을 빌드(build)하는 것에 익숙치 못한 친구들이 몇 있다. 비록 커널에 포함되어 모아져 있는 정보가 있기는 하지만, 여전히 같은 질문들이 올라오는 것을 보게 된다.

여기에 일반적으로 알아야 하지만, 내가 많은 질문을 받았던 것으로 볼 때 그렇지 못한 몇몇 가지의 팁들이 있다.

커널 팁에 관한 기사가 정규적으로 나오기를 희망한다.
다른 커널-빌더와 공유하고 싶은 것 있다면, 내게 편지를 보내거나 포럼에 써라.

• Q. 스크롤되는 것이 너무 빠릅니다. 그것 모두에 대해서 알아야 할 필요가 있나요?
  A. 아니요! 다음과 같이, 출력되는 메세지를 안 보이게 할 수 있습니다.

  	make -s zImage
  
  

  또는

  	make -s bzImage
  
  

  이렇게 하면 경과/에러 메세지만 보일 것입니다.
  
  
• Q. 제 시스템에서는 커널 컴파일이 오래 걸립니다. 빠르게 하는 방법이 없나요?
  A. 물론 있습니다! 동시에 여러 개의 파일을 컴파일 하기 위해서 리눅스의 멀티태스킹 능력을 이용할 수 있습니다. make 명령에 -j <숫자>를 추가하면 됩니다. <숫자>는 동시에 빌드 작업을 하는 작업의 수를 나타냅니다.

  	make -j 32 bzImage
  
  

  이는 동시에 32개의 파일을 빌드하여 bzImage를 만듭니다. 만약 충분한 램이 없다면, 이는 역효과를 가져올 수 있음에 주의하세요. 더 자주 스왑 영역을 필요하게 되어, 결국 성능을 저하시키기 때문입니다. 사용자의 시스템에 맞는 숫자를 알아내기 위해서는 다른 숫자로 실험을 해보시기 바랍니다. 어떤 숫자 이상에서는 CPU가 컴파일을 하는데 최대로 사용되고 있기 때문에, 작업의 숫자를 늘리는 것이 더 이상의 성능 향상을 가져오지 않습니다.
  각주를 보세요.
  
  
• Q. 지금 빌드하는 작업의 숫자가 더 빠른지, 어떻게 알아낼 수 있나요?
  A. 'time' 명령을 사용하세요.

  	time make -j 32 bzImage
  
  

  
  
  
• Q: 모듈를 빌드한 후, 'make modules_install'을 했는데 재대로 동작하지 않습니다. 무엇 때문인가요? /lib/modules/2.x.x 디렉토리안에 modules.dep 파일을 발견했는데, 그 파일을 복사/편집/해킹을 해야하나요?
  A: 아니요! make modules_install을 한 후, 'depmod -a 2.2.x'를 하세요. modules.dep가 자동으로 만들어질 것 입니다.
  
  
• Q: 시스템에 여러 개의 커널을 가지고 있는데, 부팅할 때 잘못된 System.map이라는 메세지가 뜹니다. 어떻게 각 커널에 맞는 올바른 System.map을 로딩할 수 있을까요?
  A: 전에는 Lilo의 map 옵션을 사용하라고 말했습니다. 여러 사람이 제게 지적을 했듯이 그것은 틀립니다. 이 문제에 대한 두 가지 가능성 있는 방법이 있습니다. System.map 파일을 /boot/에 하나, /usr/src/linux/에 다른 하나를 둡니다. 그러나 이는 최대 두 개의 커널 이미지만을 허용합니다. 또 다른 방법은 klogd를 시작하는 스크립트를 다시 작성하는 것입니다. 커널 버전을 확인하여(uname -r), 'System.map' 뒤에 붙인 후, 그 파일명을 -k 옵션으로 klogd로 넘기는 것입니다. RedHat 6.0에서, /etc/rc.d/init.d/syslog 파일을 고쳐야 합니다. 'daemon klogd' 줄을 다음과 같이 고칩니다:
  

  	daemon klogd -k /boot/System.map-`uname -r`
  
  

  커널을 빌드한 후, 다음 명령을 수행합니다:
  

  	mv /usr/src/linux/System.map /boot/System.map-`uname -r`
  
  

  만약 선택한 배포본에서 스크립트를 위와 같은 동작을 하도록 바꾸려는 분이 있다면, 제게 어떤 변경을 해야하는 지 알려주세요. 그것들은 한데 모아 다음에 커널-팁 기사를 쓸 때 알려드리겠습니다.
  
  
• Q: 제 시스템에는 여러 개의 커널이 있습니다. 매번 lilo.conf를 고쳐야 하는 문제가 있습니다. 더 쉬운 방법은 없나요?
  A: 가장 쉬운 방법은 lilo.conf에 vmlinuz와 vmlinuz.old를 다 가지고 있는 겁니다. (map= 항목으로 System.map과 System.map.old를 지정하고)

  (다음 예에서, 우리는 2.2.5를 돌리고 있고, 2.2.4를 백업으로 가지고 있으며, 2.2.6을 설치하려고 합니다.)
  
  
  rm -f vmlinuz vmlinuz.old system.map system.map           #심볼릭 링크 없애기
  
  rm -f vmlinuz-2.2.4 System.map-2.2.4                      #예전 커널 없애기
  
  ln -s vmlinuz-2.2.5 vmlinuz.old                           #백업 링크 설정
  
  ln -s vmlinuz-2.2.6 vmlinuz                               #새로운 커널 링크 설정
  
  ln -s System.map-2.2.5 System.map.old                     #백업 map 링크 설정
  
  ln -s System.map-2.2.6 System.map                         #새로운 map 링크 설정
  
  /sbin/lilo
  
  

  한 번에 두개 이상의 커널을 가지고 있다면, 이 작업은 더 길어질 것입니다. 그래서 일반적으로 새로운 lilo 항목을 추가하는 것이 더 쉽습니다.

정정:
한 독자가 내게 컴파일은 매우 CPU 의존적인 작업이기 때문에 단일 프로세서 시스템에서 make의 -j는 큰 차이는 없을 것이라는 내용의 편지를 보냈다. SMP 박스에서 보다 이득은 크지 않겠지만 내 시스템에서는 빌드가 더 빨라진 듯하다. 예로, 커널 2.2.3ac1을 -j 1로 98% CPU 사용율로 8m 44s에 컴파일했다. -j 32로 증가할 때, 99% CPU 사용율에 시간이 8m 1s로 줄었다. 실험해 보아라. 그 이득은 서로 다를 것이다.