기존 이솝 임베디드 포럼의 지식인 서비스가 게시판 형태로 변경되었습니다.
글 수 6,368
얼마전부터 "IT EXPERT ARM으로 배우는 임베디드 시스템"이란 책을 읽고 있습니다.
이 책에서 modified virtual address와 process id라는 개념을 설명하고 있습니다.
하지만 전 이게 왜 필요한지 전혀 이해 할 수 없습니다.
windows ce 5.0 이하에서나 32M slot의 process영역이 존재하고 이것을 mapping하는데는 도움될것 같지만
linux나 다른 OS는 그런게 아닌데 왜 MVA 변환이 context switch을 빠르게 할 수 있는지
그리고 왜 이것이 cache와 MMU에서 사용되어야 하는지 이해할 수 없습니다.
혹시나 해서 책에서 예를 들로 있는 ARM920T pdf manual을 download받아 읽어 보았지만 책내용 이상의 설명을 찾을 수없습니다.
도움 부탁드립니다.
이 책에서 modified virtual address와 process id라는 개념을 설명하고 있습니다.
하지만 전 이게 왜 필요한지 전혀 이해 할 수 없습니다.
windows ce 5.0 이하에서나 32M slot의 process영역이 존재하고 이것을 mapping하는데는 도움될것 같지만
linux나 다른 OS는 그런게 아닌데 왜 MVA 변환이 context switch을 빠르게 할 수 있는지
그리고 왜 이것이 cache와 MMU에서 사용되어야 하는지 이해할 수 없습니다.
혹시나 해서 책에서 예를 들로 있는 ARM920T pdf manual을 download받아 읽어 보았지만 책내용 이상의 설명을 찾을 수없습니다.
도움 부탁드립니다.
답변주신 김재훈님 감사드리고요. 시간내서 보겠습니다.
많이 들어본 책이지만 전산과 전공이 아니라 그 책까지 보게 되진 않더군요.
우선은 인터넷을 좀 찾아 봤습니다.아무리 생각해도 windows ce 5.0이하 버전에서만 쓸일이 있을 것 같고 windows ce 6.0 이나 linux에서는 결코 쓸일이 없는 그냥 virtual address만으로도 될 일이라고 생각했습니다. virtual memory상에서 하위 0~32M를 128개의 4G 영역으로 mapping하는게 도대체 무슨 소용인지.... process virtual address가 오직 32M라는 제약은 wince 이외의 경우에선 보질 못했는데.. 그렇담 MVA라는게 단지 wince같은 32M slot 구조의 process 영역을 할당하는 OS를 위해 고안한 것이라는 것인지...
인터넷 상에선 한글 문서는 쓸만한 내용은 하나도 찾을 수 없고 영문 문서도 MVA 그 자체를 설명하는 문서를 찾기 힘든 차에 다음과 같은 글을 찾았습니다.
For quite some time I had been thinking about the Memory Architecture of WinCE 5.0 and older kernels.
Most striking about it is the per process virtual address space of 32MB.
This is quite unique in that it offers protection between processes but allows for all virtual addresses to be unique.
This is what allows fast context switch between processes during system call and re-schedule.
As all Virtual Addresses are unique one doesn’t have to flush L1 cache and TLB during a context switch.
Recently when I was reading ARM v6 architecture I saw the FCSE (Fast Context Switch Extension) chapter.
It was clear to me in a moment where the origins of 32MB process space limit could be.
ARM MMU supports a concept of MVA (Modified Virtual Address) during address translation and this MVA is calculated by combining PID with 0 based virtual addressing scheme.
In today’s fast moving Embedded Systems world one can see that Computer Architecture and Embedded Systems are very closely related for performance reasons and a good ES designer must be savvy enough to keep track of both these worlds!
(http://goembedded.ksetindia.com/?p=57)
이사람 말에 따르면 wince뿐만 아니라 그 이전의 다른 kernel들도 32M slot 구조의 process virtual address 영역을 지원했나봅니다.
그리고 이 구조는 process간의 memory protection하면서도 각 process의 virtual address를 유일하게 하고, 이것이 process간의 context switch를 빠르게 한답니다. 그리고 각 process의 virtual address가 유일하기때문에 context switch를 할때 cache나 TLB를 flush할 필요도 없다고 하고요.(이부분은 이해가 안가는데 wince의 경우 32M slot구조지만 실제 실행되는 process는 제일 아래의 0번 slot으로 mapping이 되게 되고 그렇게 되면 실행중인 process의 virtual address영역은 결국 0~32M로 동일한 영역을 사용하게 되어 cache나 TLB를 flush해야 할 텐데말이죠. context switch가 빠르다는 것에 동의합니다.) 그런데 arm의 ProcID와 MVA, FCSE 구조를 보고 이것때문에 32M process 구조라는게 나왔구나 하고 생각했다는 군요.
즉 이 사람은 이 MVA나 ProcID 구조는 32M process 영역을 기반으로 하는 wince5.0 이하 버전이나 아니면 기타 옛날의 kernel들 위한 것이라고 판단한 모양입니다.
사실 저도 그렇게 밖에 생각이 안들거든요.
그럼 linux에서는 ProcID를 0으로 해서 VM=MVA가 되게 하여 사용한다는 말일까요?
많이 들어본 책이지만 전산과 전공이 아니라 그 책까지 보게 되진 않더군요.
우선은 인터넷을 좀 찾아 봤습니다.아무리 생각해도 windows ce 5.0이하 버전에서만 쓸일이 있을 것 같고 windows ce 6.0 이나 linux에서는 결코 쓸일이 없는 그냥 virtual address만으로도 될 일이라고 생각했습니다. virtual memory상에서 하위 0~32M를 128개의 4G 영역으로 mapping하는게 도대체 무슨 소용인지.... process virtual address가 오직 32M라는 제약은 wince 이외의 경우에선 보질 못했는데.. 그렇담 MVA라는게 단지 wince같은 32M slot 구조의 process 영역을 할당하는 OS를 위해 고안한 것이라는 것인지...
인터넷 상에선 한글 문서는 쓸만한 내용은 하나도 찾을 수 없고 영문 문서도 MVA 그 자체를 설명하는 문서를 찾기 힘든 차에 다음과 같은 글을 찾았습니다.
For quite some time I had been thinking about the Memory Architecture of WinCE 5.0 and older kernels.
Most striking about it is the per process virtual address space of 32MB.
This is quite unique in that it offers protection between processes but allows for all virtual addresses to be unique.
This is what allows fast context switch between processes during system call and re-schedule.
As all Virtual Addresses are unique one doesn’t have to flush L1 cache and TLB during a context switch.
Recently when I was reading ARM v6 architecture I saw the FCSE (Fast Context Switch Extension) chapter.
It was clear to me in a moment where the origins of 32MB process space limit could be.
ARM MMU supports a concept of MVA (Modified Virtual Address) during address translation and this MVA is calculated by combining PID with 0 based virtual addressing scheme.
In today’s fast moving Embedded Systems world one can see that Computer Architecture and Embedded Systems are very closely related for performance reasons and a good ES designer must be savvy enough to keep track of both these worlds!
(http://goembedded.ksetindia.com/?p=57)
이사람 말에 따르면 wince뿐만 아니라 그 이전의 다른 kernel들도 32M slot 구조의 process virtual address 영역을 지원했나봅니다.
그리고 이 구조는 process간의 memory protection하면서도 각 process의 virtual address를 유일하게 하고, 이것이 process간의 context switch를 빠르게 한답니다. 그리고 각 process의 virtual address가 유일하기때문에 context switch를 할때 cache나 TLB를 flush할 필요도 없다고 하고요.(이부분은 이해가 안가는데 wince의 경우 32M slot구조지만 실제 실행되는 process는 제일 아래의 0번 slot으로 mapping이 되게 되고 그렇게 되면 실행중인 process의 virtual address영역은 결국 0~32M로 동일한 영역을 사용하게 되어 cache나 TLB를 flush해야 할 텐데말이죠. context switch가 빠르다는 것에 동의합니다.) 그런데 arm의 ProcID와 MVA, FCSE 구조를 보고 이것때문에 32M process 구조라는게 나왔구나 하고 생각했다는 군요.
즉 이 사람은 이 MVA나 ProcID 구조는 32M process 영역을 기반으로 하는 wince5.0 이하 버전이나 아니면 기타 옛날의 kernel들 위한 것이라고 판단한 모양입니다.
사실 저도 그렇게 밖에 생각이 안들거든요.
그럼 linux에서는 ProcID를 0으로 해서 VM=MVA가 되게 하여 사용한다는 말일까요?
캐시메모리에서 hit가 되려면 주소를 CAM이라는데 저장을 합니다. 그런데 CAM에 저장하는 주소는 물리주소와 가상주소중 한가지를 저장하게 됩니다. 가상주소를 저장하는 방식에서 멀티프로세스 모델에서 context switching이 발생하면 프로세스마다 가상주소가 같아서 캐시나 TLB 플러시를 해줘야합니다. 그래서 MVA를 CAM에 저장하는 방식을 사용하여 캐시나 TLB 플러시를 피할 수 있지만 32M보다 큰 프로세스의 경우에는 마찬가지로 오버헤드가 발생하게 됩니다. 그래서 큰 프로세스를 지원하기 위하여 ARM11 부터는 물리주소를 CAM에 저장하기 시작합니다.
6판의 경우 한국어 판이니 한번쯤 읽어보시면, 말씀하신 의문점 이외에도 이해 안되시는 부분에 대해서도
많은 참고가 될 수 있을 것 입니다. :)