week2_0313.md

• x86 아키텍처는 왜 레지스터를 아껴 써야 하는가?

  x86 아키텍처라 함은 관습적으로 x86-64 이전 아키텍쳐를 말하며 당시 x86 아키텍처의 단점으로는 여타 아키텍처에 비해 레지스터 수가 적다는 것이었다. x86-16과 x86-32기준으로 14개의 레지스터를 갖고 있으며 이 중 범용 레지스터의 수는 4개이다. x86 아키텍처의 레지스터 용량 문제도 생각해보았을 때 그렇다면 왜 레지스터의 개수를 늘리지 않았을까? 라는 의문이 든다.
  이후의 AMD64 아키텍처에서 레지스터의 개수와 용량을 늘려 문제점을 해결한 것을 비추어 보았을 때 그 시대 당시의 CPU 설계자들의 기술적 한계점과 레지스터 개수를 늘리면 발생하는 가격 간에 trade off를 고려한 것이 아닌가 생각된다.

  레지스터의 용량과 개수가 적은 것은 시대 당시 기술적 한계와 비용 문제

• 프로세스 와 스레드 의 차이는 무엇인가?

  • 프로세스

    현재 실행되고 있는 프로그램

    • 운영체제로 부터 메모리를 할당받으며 스케줄링의 대상이 된다.

  • 스레드

    프로세스 안에 존재하는 실행의 흐름

    • 최소 하나 이상이 존재하며 프로세스의 메모리 자원을 공유

  • 리눅스에서의 스레드

    리눅스에서는 프로세스 자체가 충분히 가벼우며 스레드는 단지 자원을 공유하는 프로세스라고 정의한다.

  • 리눅스에서 스레드 개념을 별도로 정의하지 않고, 단지 자원을 공유하는 프로세스 의 형태로 구현하는 이유는 무엇인가?

    리눅스는 다른 운영체제와 다르게 프로세스 생성을 fork()와 exec()의 두 가지 단계로 구분하여 생성하게 된다. fork()를 수행하는 과정에서 별도의 플래그를 사용하여 부모프로세스 와 자식프로세스 간에 자원을 공유하게 한다면 이것이 스레드 의 개념과 같게 동작하는 것을 기대할 수 있다. 굳이 기존의 개념으로 스레드 를 정의할 수 있다면 별도의 개념을 도입할 필요성을 느끼기 힘들다.

    clone(CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND, 0); 이 코드는 주소 공간, 파일시스템 자원, 파일 서술자, 시그널 핸들러를 공유하는 fork() 시스템 호출과 같다.

• 커널이 부모프로세스 보다 자식프로세스 를 의도적으로 먼저 실행해야 하는 이유는 무엇인가?

  리눅스에서는 Copy-on-Write 기능을 제공한다. copy-on-write 는 기록사항 발생 시 복사 라는 뜻이며 fork()로 만들어진 자식프로세스 에 대한 리소스 기록이 발생할 때까지 페이지 복사 작업을 지연시키는 방법으로 리소스 낭비를 최소화한다. 관습적으로 자식프로세스 는 fork() 뒤에 다른 실행파일로 exec()을 하기에 추가로 메모리를 복사할 상황이 적을 것이지만 부모프로세스 는 fork() 뒤에 어떤 동작이 올지 모르며 쓰기 동작을 수행 시 내용이 변경된 페이지만 따로 복사를 하게 되는 비용이 발생하게 된다.

  • 왜 아직까지 제대로 동작하지 않는가?

    프로세스 생성 시에 자식프로세스 가 부모프로세스 보다 먼저 실행되기를 기대하나 아직까진 잘되지 않는다고 한다. 리눅스의 프로세스 계층 특성상 모든 프로세스가 부모프로세스 자식프로세스 관계를 가진다. 자식프로세스 에게 우선순위를 부여해 주면 최악의 상황에서 부모프로세스 는 계속 우선순위가 밀려 실행되지 않는 상황이 발생할 수 있다. 갓 fork()된 자식프로세스 에게 우선순위를 부여하는 방법도 생각해 볼 수 있겠는데 기술적으로 아직 구현이 안 되는 것이 아닌가 유추해 본다.

• CFS 스케줄러 는 O(1) 스케줄러 의 어떤 문제점을 해결하였으며, CFS 스케줄러 가 가지는 한계는 무엇인가?

  • O(1) 스케줄러 의 문제점(부작용)

    • 나이스 값에 따라 타임슬라이스 를 고정 할당하기에 작업전환 최적화가 어렵다.

      • 나이스 값 이 0인 두 개의 프로세스가 존재할 때 100ms의 타임슬라이스 를 할당하게 되며 작업전환이 100ms마다 일어나게 되어 효과적인 타임슬라이스 할당이라고 볼 수 없다.
      • 나이스 값 이 20인 두 개의 프로세스가 존재할 때 5ms의 타임슬라이스 를 할당받아 작업전환이 너무 빈번히 일어나 문맥전환 비용이 너무 많이 발생하게 된다.

    • 나이스 값에 따라 타임슬라이스 의 상대적인 차이가 발생한다.

      • 나이스 값이 0과 1인 경우와 19 20인 경우를 생각해보면 타임슬라이스 의 비율이 각각 100:95 와 10:5 이다. 각각 나이스 값 에서 단지 1의 차이를 보일지라도 전자의 타임슬라이스는 근소한 차이를 보이며, 후자는 그 차이가 두 배가 된다.

    • 운영체제마다 타임슬라이스 의 길이가 달라질 수 있다.

      • 나이스 값 에 따라 타임슬라이스 의 절댓값을 할당할 수 있어야 하며 이는 커널이 측정할 수 있는 단위로 정해져야 한다. 그렇기에 운영체제의 타이머 클럭의 일정 배수로 타임슬라이스 단위를 정하게 되는데 운영체제마다 타이머 틱 값이 다르므로 운영체제에 따라 타임슬라이스의 크기가 달라지는 문제점이 발생하게 된다.

    • 우선순위 기반 스케줄러 가 대화형 작업 최적화 시 불공정 할당 문제가 발생한다.

      • 대화형 프로세스가 할당받은 타임슬라이스 를 모두 소진 후 잠들어 있을 때 키보드 입력 등의 인터럽트가 발생하여 대화형 프로세스를 깨우는 상황이 일어나면 대화형 성능을 향상할 수 있겠으나, 나머지 시스템을 희생시켜 한 프로세스에만 불공정하게 프로세서를 할당하게 되는 허점이 발생한다.

  • CFS 스케줄러 의 스케줄링

    • 프로세스에 할당할 프로세서 시간 비율의 가중치로 나이스 값 을 사용한다. 나이스 값 이 높을수록 낮은 비율의 가중치를 낮을수록 높은 비율의 가중치를 받으며 O(1) 스케줄러 의 타임슬라이스 상대적 차이를 해결할 수 있다.

    • 완전 멀티태스킹의 무한히 작은 스케줄링 단위를 근사한 목표 응답시간 을 설정한다. 이 시간 안에 모든 프로세스가 1번씩 실행되게 하며 이 시간이 짧을수록 대화형 성능이 좋아지게 된다. 목표 응답시간 을 도입해 O(1) 스케줄러 의 문제점인 타임슬라이스 고정 할당 문제, 운영체제마다 타임슬라이스 가 다른 문제와 대화형 최적화 시 불공정 할당 문제를 해결하였다.

  • CFS 스케줄러 의 한계점

    • 실행 중인 프로세스가 많아지면 받아들일 수 없는 수준의 전환 비용이 발생한다. 프로세스가 많아지면 그만큼 타임슬라이스가 작아지게 되며 타임슬라이스가 너무 작아지게 되면 문맥 전환 비용이 커지기에 최소 세밀도 인 1ms 이하로는 쪼개질 수 없게 하였다.

      목표 응답시간 이 20ms 일 때 프로세스가 100개가 되면 어떻게 되는가?

  • 리눅스가 두 가지 별개의 우선순위 단위 (나이스 값, 실시간 우선순위) 를 가지는 이유는 무엇인가?

    효과적인 스케줄링을 위해 도입한 개념으로 생각되며 나이스 값 만으로는 대화형과 같은 프로세스의 우선순위를 계산하기 어려우며 실시간 우선순위만으로는 대화형 프로세스에만 큰 우선순위를 부여하면 불공정 스케줄링 문제점을 보완하기 위해 두 가지의 우선순위 단위를 사용한 것으로 생각한다.