파이프라인과 캐시 미스, 컨텍스트 스위치에 관한 질문드립니다.
글쓴이: nicelhc13 / 작성시간: 목, 2015/04/02 - 1:54오전
안녕하세요
다름아니라 캐시 미스가 나서 메모리를 찾으면, 혹은 TLB나 Page Table에서 Page fault가 감지되어 Disk I/O 할때 Pipeline이 stall되는 상태로 대기한다고 배웠습니다.
만약 Disk I/O가 되고 있는 상황이라면 그 프로세스는 Context switching되고 CPU 입장에선 다른 프로세스가 작업을 시작하겠죠
여기서 조금 이해가 안되네요
파이프라인이 스톨된 상태이면 아무 작업도 없어야 하는데, Context switch 되서 다른 작업을 하고 있어야 하고 실제로 하고 있는것 같은데
어떻게 이것을 설명해야할까요?
제가 잘못생각하거나 모르는 하드웨어적 내용이 있다면 설명해주실 수 있나요?
감사합니다 ㅎㅎ
Forums:
의견
> 다름아니라 캐시 미스가 나서 메모리를 찾으면, 혹은 TLB나 Page Table에서 Page fault가
> 감지되어 Disk I/O 할때 Pipeline이 stall되는 > 태로 대기한다고 배웠습니다.
우선, 여기 문맥에서 얘기하는 것이 CPU의 Pipeline이 아닌 것 같다는 생각이 들구요.
Disk I/O에 동작 중에 메모리에 쓸려고 할 때, 메모리가 실제 Pysical 메모리에 할당이 안되면 Page fault가 일어나고
그 때서야 Dynamic하게 페이지를 할당하거나 잘못된 어드레인 경우 예외처리하겠죠. 따라서 Disk I/O는
대기하는 상태이구요.
>파이프라인이 스톨된 상태이면 아무 작업도 없어야 하는데,
여기서의 파이프라인에 Disk I/O queue라고 보면 Context switch 되서 다른 작업을 해도 무방한 것 같습니다.
감사합니다만 아직도 다소 헷갈리는 부분이 있네요ㅜㅜ
먼저 답글 달아주셔서 감사합니다. 그러나 제가 부족하여 여전히 이해가 안되는 부분이 있는데 한 번더 여쭤봐도 될까요?
문맥이 CPU의 Pipeline이 아니지만, 어쨌든 문맥이 수행되려면 최종적으로 CPU의 파이프라인에서 인스트럭션들을 수행하는 것이 아닌지요??
그러니까
학부때 OS 수업 중 Disk I/O 인터럽트가 발생해 프로세스가 Disk I/O 큐에 들어가 대기한 다는 것도 배웠고, 컴구 시간에 캐시가 Disk I/O 수행 중에 파이프라인의 다음 인스트럭션을 noop로 만들어 대기한다고도 배웠습니다
제 부족한 설명으로 다시한번 질문드리자면 ㅜㅜ
CPU가 어쨌든 인스트럭션들을 파이프라인에서 패치하고 연산 한다고 알고 있습니다.
즉 CPU가 문맥교환을 해서 다른 프로세스가 돌아간다 해도 최종적으로(그러니까 제일 로우로 갔을 때) CPU 파이프라인에서 처리한다고 저는 생각합니다
그러나 컴구 시간에는 디스크 I/O가 일어났을떄 파이프라인 자체를 멈춘다고 배웠습니다.
그럼 최종적으로 CPU는 아무 작업을 안해야 하는데 분명히 문맥교환하여 다른 작업을 파이프라인에서 처리하지 않나요?
파이프라인이 몇 개 더있는건가요 ?아니면 Disk I/O시 다음 명령어들을 스톨하고 멈춘다는게, 현재 프로세서에 대한 인스트럭션들을 다 없애버리고 문맥교환된 새로운 프로세ㅅ의 내용으로 채운 다는 뜻인지요?
부족한 제글을 읽고 답글 달아주셔서 다시한번 감사합니다.
의견
>문맥이 CPU의 Pipeline이 아니지만, 어쨌든 문맥이
>수행되려면 최종적으로 CPU의 파이프라인에
>서 인스트럭션들을 수행하는 것이 아닌지요??
맞습니다. 그렇죠.
주어진 상황을 바탕으로 다시 이야기를 만들어 보면
#1 프로세서 P1 작동 시작
#2 P1 이 DISK I/O 동작중에 특정 메모리 접근
#3 페이지 폴트 발생
#4 메모리 매핑 -> 페이지 테이블 업데이트 (가상과 물리적 메모리 새로운 짝패)
#5 Flush TLB -> Flush CPU Pipeline (사실 특정 CPU마다 약간 다릅니다.)
#6 Context Switch
#7 프로세서 P2 동작 시작
#8 P2가 특정 함수 실행
#9 특정 함수 실행 중, CPU Pipeline에서 Nop/ Stall 발생 (CPU Hazard 피하기 위해)
두 가지 내용이 섞인듯 합니다.
1. CPU는 Disk가 보이지 않습니다. memory mapped IO든 IO mapped IO든 memory access 명령어를 수행할 뿐입니다.
CPU pipeline이 stall되면 그 만큼 성능이 하락할 뿐입니다.
2. Disk I/O처럼 CPU 성능대비 대기시간이 긴경우, kernel 혹은 OS는 Hardware 동작을 기다리는 대신 context switching을 합니다.
Hardware 동작이 완료되면, interrupt가 발생되어 다시 해당 프로세스를 수행 합니다.
> 그러나 컴구 시간에는 디스크 I/O가 일어났을떄 파이프라인 자체를 멈춘다고 배웠습니다.
위 내용을 다시 확인하시는게 나을것 같습니다.
OS Disk I/O와 컴구에서 I/O (hardware 영역 access)를 혼동하여 한 질문으로 보입니다.
아니면, 질문에서 설명하지 않은 내용이을 찾을 수도 있습니다. (Disk swap이라든지...)
pipeline stall, cache miss는
pipeline stall, cache miss는 cpu 속도 올리려고 온갖 트릭을 쓰는 과정에서 발생한 것이기 때문에 cpu 내부에서 알아서 처리합니다. tlb도 말씀하셨는데 tlb는 메모리에 있는 page table을 참조할때마다 매번 메모리 접근하지 않을려고 만든 cpu내의 페이지테이블 임시버퍼입니다. 이것도 당연히 cpu가 알아서 처리합니다. 프로그래머가 이들을 직접 조작하는 경우는 NUMA 시스템 등에서 특정 시점에 특정 메모리로 데이터가 들어갔다는 것을 확실하게 보장하기 위해서 캐시 강제로 비운다거나 하는 경우밖에 없습니다.
그렇지만 page fault, context switch 같은 경우는 OS의 시스템 관리방식과 외부장치 입출력이 필요하기 때문에 cpu가 단독으로 결정 못합니다.
메모리 할당/해제를 page table 변경도 마찬가지고요. OS레벨에서 처리 해줘야죠. 리눅스와 윈도우가 메모리 관리방식이 다르니 이걸 cpu가 자동으로 해줄수는 없죠.
프로세스가 Disk I/O 걸렸다면 Disk I/O 요청 들어가면 CPU 시간 배분해도 Disk에서 데이터 오기 전까지는 아무것도 못하고 멈춘 상태가 되니 그 시간을 차라리 다른 프로세스에게 넘겨버리는게 더 이득이니 Context Switching으로 다른 프로세스에게 넘겨버리는겁니다. 이것도 OS의 프로세스 관리 방식에 따라 다 다릅니다.
아 그리고 어셈블리 해보신분은 아시겠지만 CPU는 메모리만 다룹니다. 가끔가다 외부 전용 입출력을 달고 이에 대한 명령어를 제공하는 CPU도 있지만요. x86이라면 in, out이 이에 해당되는데 이건 키보드 같이 가끔 데이터가 왔다갔다 하는 경우에나 쓰지 다량의 데이터가 왔다갔다하는 주변장치들은 다 memory-mapped I/O 입니다. 쉽게 설명하자면 특정 메모리 주소에 read/write하면 실제 메모리가 아닌 외부장치로 날라가는겁니다.
Written By the Black Knight of Destruction
댓글 달기