SSE3044: Operating Systems (Fall 2015)

[Projects]

TA : 현병훈 mail : gusqudgnskku@gmail.com

pintos 설치 메뉴얼 : 메뉴얼

Project 0: Warming Up

   Due date : 9/11 11:59PM
   project0

환경변수 설정관련

   매번 환경변수(PATH)를 설정하기 귀찮으신 분들은 root권한에서 (sudo su)
   vi ~/.bashrc
   에 들어가셔서 맨 아래줄에 export PATH=$PATH:/home/자기 디렉토리/
   를 입력하시고 다시 terminal를 여시면 항상 해당 환경 변수가 추가됨을 확인하실수 있습니다.

Project 1-1: alarm, priority_scheduler, priority_donate

   Due date : 9/22 11:59PM
   project1-1

Project 1-2: BSD Scheduler

   Due date : 10/3 11:59PM
   BSD Scheduler 는 Pintos Document를 보고 그대로 만드세요.

Project 1: 구두테스트 시간적으세요 (한칸당 3명 가능)

  https://docs.google.com/spreadsheets/d/1L7bS8GyHJgqJEElnQDKUngw7k3vdOJdqaUY0iQFNJgE/edit?usp=sharing

Project 1번 관련하여

  대부분의 학생들이 pintos 1번의 test case를 통과하였습니다.
  하지만 1번 project의 test case가 모든 경우의 시나리오를 완벅하게
  확인해 주지 못한다는점 인지하시길 바랍니다.

  ex)
   1. sema_down의 lock->semaphore.waiters에  list_insert_ordered로 리스트에 추가하고
   sema_up의 lock->semaphore.waiters에서 list_pop_front를 하는 경우

   -> nest-priority donation이 발생할때 과연 semaphore.waiters의
      list 정렬이 파괴되지 않는가?


   2. thread_tick()함수내부에서 4tick마다 thread_yield를 호출하게 되어있는데
   priority scheduling이 수행되는 관점에서 이러한 코드가 꼭 필요한가?


   3. thread 수가 무한히 증가하는 환경에서 list로 관리하는 것이 항상 효과적인가?
      Big_o 가 리스트의 경우 O(n)입니다.

     -> 이 경우는 몇몇 학생들이 O(1) 복잡도의 scheduler를 구현하였으며,
        3번과제를 수행해서 thread의 수가 많아질 경우 performance의 차이로 나타날수 있습니다.


   4. interrupt를 끄고 켜는 부분을 마구잡이로 사용해도 되는가?

     -> 리스트를 사용할 경우 intr_disable()를 사용하여 인터럽트를 끄는데 필요없는 부분에서도
     intr_disable()이 사용되는 경우가 종종 발견됩니다. 이에 대해 좀 더 고민해 보시길
     바랍니다.

pintos 2 파일 시스템 관련 메뉴얼 : fs메뉴얼

Project 2: Userprogram (ARG parsing, PCB 구현, 시스템 콜 구현)

   Due date : 10/31 11:59PM
   project2


   Prject_2 추천 Due date
   1. 10/12 까지 Arg parsing, exec, wait system call 구현
   2. 시험 공부 열심히 하기
   3. 시험 공부 끝나고 나머지 system call 구현하기


   위에서 추천드리는 가이드 라인대로 TA시간을 운영하고자 합니다.

   따라서 10/12일 TA시간에는 exec, wait, arg parsing, PCB구현 관련 TA를 진행할 예정이니
   해당 부분에 궁금한 점 있으면 저녁 9시에 참석해 주시면 감사하겠습니다.

시험과 관련되서 구두테스트를 연기해 달라는 몇몇 문의가 있어서 아래 excel로 통일합니다. 기록해주세요. 구두테스트는 자신의 알고리즘 관련 질문 + 시험지 확인 으로 구성됩니다. https://docs.google.com/spreadsheets/d/1L7bS8GyHJgqJEElnQDKUngw7k3vdOJdqaUY0iQFNJgE/edit?usp=sharing


Project 3번 점수 반영과 관련하여

     -> 3번 점수 반영과 관련하여
        3번의 make check 는 project2번과 project3번을 모두 확인하는 check입니다.
        해당 check로는 stack growth, mmap, swap, systemcall을 확인가능합니다.

        따라서 우선 system call의 비중인 35%를 제외 하겠습니다.
        (2번이 제대로 구현 안된 경우에는 관련 점수가 낮게 반영될 수 있습니다.)

        나머지 65%에 대해서 stack growth, mmap, lazy loading, swap 을
        15 : 15 : 15 : 20 의 비율로 반영하여 점수를 재 계산합니다.

        따라서 
        score = grade - 35%
        자신의 stack grouth, mmap, swap의 점수가 됩니다.

        여기에 추가적으로 lazy loading의 구현 여부에 따라서 -15를 부여합니다.

        ex)
        lazy loading 구현 : grade - 35% - 15%
        lazy loading 미구현 : grade - 35%

        그 이후 전체 값인 65%를 100으로 정규화 해서 최종 점수를 구하였습니다.

        각각의 스코어는 구현 정도에 따라서 점수를 차등 부여하였습니다.


        관련 문의 사항있으시면 이번주 금요일까지 mail, 문자를 통해서 클레임을
        받겠습니다. 

최종스코어

ID 끝 3자리project0project1project2project3
7521001009432.4
384100100949.3
56110010085.77.2
4111001009815.2
7841001009036.3
707100100940
5411001009236.3
3011001009311
2451001009765
8051001008590
75610090805.8
240100100946.4
9951001009032.4
831100908033.3
5781001008066.15
3181001009532.4
481100100925.07
292100100900
4091001009669.2
27110010010090