본문 바로가기

잡담

리눅스 커널세미나

내가 중학교 때 한창 Visual Baisc 6.0을 다루면서, 왜 Windows API를 통한 타이머의 최장 간격에 제한이 생길까 궁금해했던 적이 있었다. 그때는 단순히 32bit Long 데이터형의 overflow 때문이겠지 생각하고 넘어갔었는데, 오늘 커널세미나를 들으면서 좀더 자세히 알게 되었다.

리눅스 시스템에서 어떻게 시간 측정을 하고, Tick을 발생시키고 계산하는지에 관한 내용이었는데, 시스템 프로그래밍 프로젝트를 하면서 왜 패킷 전송을 지연시키기 위해 usleep 함수를 쓸 때 어느 정도 시간 이상을 주어야 했는지(내가 당시 의도했던 건 다른 프로세스가 스케쥴링되게 하여 패킷 전송 간격을 벌리는 거였다.), 또한 gettimeofday 같은 함수가 어떻게 동작하는 것인지, 아주 작은 시간 간격을 타이머로 지정할 때 문제가 생기는 이유가 무엇인지 알 수 있었다. 또한 jiffies와 HZ 상수에 의해 타이머 간격의 최대값이 결정된다는 사실을 알았다. (HZ가 1000인 경우 49.7일이 된다)

아주 조금이지만, 커널을 들여다보니 상당히 흥미롭다. 내가 프로그래밍하면서 가졌던 소소한 의문들에 대해서, 왜 그럴 수밖에 없었는지, 왜 그런 현상이 나타나는지 알 수 있었다.

내가 어렸을 때 신기하게 느낀 것 중 하나가, 프로그램을 한 번 실행하고 나면, 그 다음 번에 실행할 때는 훨씬 빠르다는 것이었다. 파일을 읽을 때도 마찬가지였고. 근데 시스템 재부팅을 하거나, 그 프로그램을 오랫동안 쓰지 않다가 다시 실행하면 처음 실행할 때만큼 시간이 걸린다는 점이었다. (이걸 어느 순간 느꼈던 것은 아니고 오랜 동안의 경험이 쌓이면서 이런 동작이 이뤄진다는 것을 알 수 있었다)

다음 주에 내가 세미나를 맡은 부분이 Page Caching에 관한 부분이다. 미리 조금 읽어보았는데, I/O 속도를 높이기 위해서 파일 단위(inode)로 page 정보 구조체를 두고 읽으려고 하는 부분을 메모리에 올려 cache하는 방법이다. 이렇게 해서 반복적으로 같은 곳을 읽게 되면 실제로는 파일을 읽는 게 아니라 메모리를 읽게 되므로 속도가 빨라지는 것이다. 거꾸로 그 위치에 기록하게 되면, 커널에서는 그 page cache를 'dirty' 상태로 표시하는데, 이것은 해당 내용이 변경되었으니 언젠가 디스크로 기록되어야 함을 뜻한다. 커널 내에 pdflush 데몬이라는 것이 있어서 적당한 시점이 이것을 실제 디스크에 기록해주는데, 오랫동안 해당 cache를 사용하지 않는 경우나 메모리가 부족한 경우에 행해지게 된다.

이것은 내가 경험적으로 느꼈던 것과 거의 일치하는 설명이다. 특히 소스코드를 컴파일할 때 이런 걸 많이 느끼는데, 컴퓨터를 켜고 처음 컴파일할 땐 무지 느리지만 그 다음부터는 별로 디스크를 긁지 않고도 슥슥 되는 것을 볼 수 있다. (원격 콘솔로 작업할 때도 그 차이가 느껴질 정도다)

이렇게 막연히 그럴 것이다라고 생각했던 사실들을 커널을 아주 조금만 들여다봤음에도 하나하나 알게 되는 것이 정말 매력있는 것 같다. 비록 내가 요즘 주로 쓰는 건 php, python, java 같은 매우 고수준/스크립트 언어들이지만, 그 내부에서 동작하는 것을 알게 되니까 대충 그럴 것이다라고 넘어갔던 것들에 대해 확실한 감이 오고, 성능 최적화나 어떻게 접근하는 것이 시스템에 무리를 덜 줄 지와 같은 문제들을 생각할 수 있을 것 같다. (아직은 그만한 경험이 없지만 말이다)

또 하나 흥미로운 건, 최근 나오는 Dual Core / Dual CPU 시스템들의 경우 각 코어가 완전히 따로 동작함으로써 발생하는 각종 race condition들에 대한 처리와 같은 것들이다. 세미나의 원래 목적인 Virtualization 기술에서도 가장 문제가 되는 부분이기도 하고. 아직은 아는 게 별로 없어서 구체적인 내용은 모르겠지만, 내용이 조금 어렵고 방대하긴 해도 즐겁게 들을 수 있는 세미나가 될 것 같다.
  • 코카스 2006.08.04 03:47

    음.. 듀얼 코어 시스템이 기존의 SMP와 어떻게 다른지도 궁금하네요. :)
    면접 준비 하면서 알아봐야겠습니다.

  • clowcard 2006.08.04 14:38

    심지어는 하드 안에서조차 자주 읽는 쪽을 특정 영역에 모아두어 seek time을 줄이기도 하지 'ㅅ'
    아직 여러개의 CPU가 있어도 최적화해서 병렬처리하기란 힘들어
    저걸 최적화해서 분배하려면 또 그거 계산하느라 시간 뺏기기도 하니 ㄱ-
    thread group 자체를 나눠서 배치하는 식으로 load balancing을 하면 되긴 하겠지만
    하나의 그룹이 무지무지 CPU를 많이 먹는 놈이면 또 얘기가 달라지지 'ㅅ'
    아무튼 병렬처리 나름 재밌는(정말?) 분야

    • daybreaker 2006.08.20 23:10 신고

      세미나 더 들어보니까 I/O 스케쥴링할 때도 어떤 장치냐에 따라서 다른 알고리즘을 사용하기도 하고 내부적으로 최적화가 많이 되어 있더라구요. 간단한 아아디어로 상당한 성능 향상을 가져오는 경우도 있다는 게 신기했습니다.;

  • ghd 2013.07.19 03:33

    태양이 바다에 미광을 비추면,나는 너를 생각한다.