[운영체제] 5. I/O(입출력) - 2

디스크에서 최적화 하는 알고리즘.

lotation delay와 transfer time은 줄이기 힘듦. 거의 고정, 에러 체킹은 컨트롤러에서 하니까 빼고.

실제 dominent(지배적인)한 sector는 seek time이 i/o time에 영향을 끼침 -> seek time을 줄여야 함.

work conserving : 해야할 일이 있을 때 계속 하는 것. ex) CPU

non-work conserving : 디스크는 해야할 일이 있어도 기다리는게 이득일 수 있음.

 

request order : 읽어야 할 트랙 번호.

FIFO: 온 순서대로 처리 -> 공정하지만, (헤드 이동 거리)시크타임은 커짐

SSTF: 헤드 이동거리가 가장 짧은 요청 선택하여 처리 -> 시크타임이 짧아지나, starvation 발생

스캔 알고리즘  : 한 쪽 방향으로 쭉 진행 : 가운데의 데이터들의 서비스율이 높음 -> 어플리케이션 최적화 할 때 데이터 배치를 플래터의 가운데에 배치하는 알고리즘도 있음 -> 어쨌든 서비스의 편차가 크다.

 

C-scan : 한 쪽 방향으로 하고, 헤드를 다시 옮김. 모든 트랙이 공평하게 서비스 받음, 그러나 이동거리는 길어짐.

N스텝스캔 : 큐가 여러개, 세그먼트가 쭉 쌓이면 하나를 서비스 시작, 다 차면 다음큐로.

F스캔 : 큐 두개로 나누어서 하나 처리하고 다음큐에 쌓고, 또 그거 처리하고 빈 큐에 쌓고.

-> 현재 헤드 위치 주변에 요쳥된 리퀘스트를 먼저 처리하는 페어리스 문제를 해결.

 

속도는  SSTF>SCAN>CSCAN>FIFO, 스캔류 많이 쓰고 SSD에서는 정렬 의미가 없어서 피포 쓰기도 함.

 

디스크는 에러가 많아 트랙마다 스페어 섹터를 둠.

b : 직접적으로 배드섹터를 뒤쪽으로 매핑 -> 순차 읽기가 어려움.

c :  배드섹터를 건너뛰고 매핑. -> 데이터를 뒤로 다 밀어야 함.

-> 인터리빙 할 때 트랙 버퍼 있으니까 그냥 b처럼 함.

 

스테이블 스토리지 : 똑같은 디스크를 2개 씀.

b : 1번 쓰다가 크래시 -> 2번에서 복사 : 이전 상태로 돌아감

c : 1번에 쓰고 2번 쓰기전에 크래시 : 롤백하거나, 새로운 데이터로 2번에 복사

d : 2번쓰다 에러났으니 1번에서 복사

e : 다 쓰고 에러나서 상관없음. -> 비용도 속도도 안좋아서 쓰지 않아요.

 

클록 하드웨어 : 메인보드에 수정 진동자를 달아서, 클록을 만듦.

홀딩 레지스터에 1초에 몇번의 클록 인터럽트 발생시킬건지 세팅 -> 이 값을 카운터에 복사

-> 클록이 나올 떄 마다 카운터 감소시키고, 0이 되면 인터럽트 발생시켜서 CPU로 가고, CPU는 핸들러 수행.

너무 많이 발생하면 프로세스 수행에 방해되기에 적정한 수준 유지 중요. : 이렇게 동작하는게 programmable clock.

 

클록 인터럽트가 발생해서 클록 드라이버가 하는일

1. 시간정보 유지

2. 프로세스가 타임슬라이스만큼 CPU 썼는지 판단하여 스케쥴링 코드 실행

3. CPU 사용시간 저장

4. 사용자, 유저 프로세스의 알람 시그널 처리

5. 시스템에서 와치독 세팅 -> 지정시간에 프로그램 처리

6. 프로파일링, 모니터링, 통계정보 모으기

이 시간 정보 유지하는 방법은 3가지

a. 64비트 레지스터 사용 -> 1970 0101 기준으로 몇 번의 틱 발생했는지 저장하여 날짜 계산

b. 32비트 워드 가지고 초 단위로 몇 번의 클록틱(인터럽트)이 발생했는지 저장

c. 부팅 후 시간이 얼마나 지났는지 유지

 

해야할 일이 많아 효율적으로 하기 위해 헤드에 해야할 일을 모아둠

클록 인터럽트가 뜨면 해야할 일을 헤드에서 찾고 -> 인터럽트마다 시간 하나씩 죽이면서 그 일의 시그널을 1씩 내림

-> 헤드 따라가면 일을 처리해야할 지 말 지 결정 가능

 

소프트 타이머

클록틱을 1초에 100번, resolution을 1/500으로 줄여서 타이머 설정하면, 정상적으로 정확히 실행이 안되겠지.

-> 조금이라도 가깝게 하는게 소프트 타이머

 

운영체제는 시스템 콜 인터페이스를 제공하고, 커널코드는 자주 실행 -> 부분부분 커널 타이머를 체크하도록 함.

중간중간 커널이 소프트 타이머가 expire(만료) 되었는지 확인해서 등록된 태스크 실행.

 

옛날 얘기 : 터미널 통해 중대형 서버 사용 -> 임베디드 시스템에서 디버깅 용도로 사용함.

터미널에선 전부 텍스트 -> 데이터를 서버가 갖고 있음 -> 터미널마다 버퍼를 가짐.

센트럴 버퍼 풀 -> 조금씩 메모리를 할당해서 화면에 표시된 텍스트 데이터 저장

-> 남는 부분 아까우니까 조금만 할당

터미널 제어를 위해 컨트롤 키도 존재 -> 컨트롤 q s, 이에스시 뭐이런거...?

 

그래픽을 읽을 필요가 생겨서, 그래픽 어댑터를 만듦

-> 비디오 컨트롤러는 VRAM에 있는 데이터를 읽어 화면에 업데이트, 이걸 바꿔주는 디바이스 드라이버를 사용하여 데이터를 바꾸면 화면을 바꿀 수 있었음.

화면 사이즈가 80*25였는데. VRAM은 한 줄에 160 캐릭터임. A가 표시되고, 색상 깜빡임 같은 속성이 더 들어감.

 

인풋 소프트웨어 : 키보드가 눌리면 드라이버로 숫자(스캔코드) 전송 -> 아스키 테이블 통해 캐릭터로 변환

-> 키 맵과 한글 코드 페이지가 필요. -> 지금은 유니코드 사용

 

엑스 윈도우 시스템 : 그래픽 터미널을 위해 첫번째로 만들어진 것.

호스트에 있는게 클라이언트, 컴퓨터에 있는게 서버 -> 반대 아니냐?

데이터를 입력하면 호스트로 전달 -> 데이터 처리 해서 터미널로 화면에 그림 그려달라고 요청(엑스서버로 메세지를 전달)

-> 화면에 엑스서버가 그림을 그려줌 : 그림 그려주는 역할을 해서 화면이 서버

-> 물리적인 터미널은 없지만 소프트웨어적으로 남아 있음.

 

X11로 프로그래밍 : 메세지 주고받아야 하니 메세지 루트가 있고, 이벤트 타입에 따라 처리 (2)

과거 비주얼 C++ (4)

메세지 발생하면 해석, 처리, 가져오기 실제처리 한 부분 (5) 

중요 x

 

비트맵은 9바이 8. 컬러일 경우 9*8*3만큼 메모리 필요.

이걸로 폰트 만들면 우측 처럼 되고, 확대하면 깨짐 -> 트루타입으로 벡터방식으로 저장.

 

과거 씬 클라이언트 : 은행 텔러 시스템 : 메인프레임이 있고, 텔러는 클라이언트에 앉아 특정작업만 수행

-> 제조비용 줄이기 -> 갈수록 비효율

 

활성화 되지 않은 화면 백라이트 꺼서 전력소모 줄이기 -> 티끌모아 태산

클록스피드를 반으로 줄이면 전력 소모가 1/4로 줄고, 시간이 2배 걸리게 됨. -> 에너지는 절반으로 줆