KR20130114023A - 멀티 프로세서 시스템 온 칩에서의 메모리 관리 방법 - Google Patents

멀티 프로세서 시스템 온 칩에서의 메모리 관리 방법 Download PDF

Info

Publication number
KR20130114023A
KR20130114023A KR1020130100570A KR20130100570A KR20130114023A KR 20130114023 A KR20130114023 A KR 20130114023A KR 1020130100570 A KR1020130100570 A KR 1020130100570A KR 20130100570 A KR20130100570 A KR 20130100570A KR 20130114023 A KR20130114023 A KR 20130114023A
Authority
KR
South Korea
Prior art keywords
memory
function
size
area
allocated
Prior art date
Application number
KR1020130100570A
Other languages
English (en)
Other versions
KR101334189B1 (ko
Inventor
유정준
임근수
신용삼
김한철
이승원
이재돈
정민규
Original Assignee
삼성전자주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 삼성전자주식회사 filed Critical 삼성전자주식회사
Priority to KR1020130100570A priority Critical patent/KR101334189B1/ko
Publication of KR20130114023A publication Critical patent/KR20130114023A/ko
Application granted granted Critical
Publication of KR101334189B1 publication Critical patent/KR101334189B1/ko

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Devices For Executing Special Programs (AREA)

Abstract

본 발명의 일 실시 예는 멀티 프로세서 시스템 온 칩에서의 메모리 관리 방법에 관한 것으로, 본 발명의 일 실시 예에 따른 메모리 관리 방법은 소정의 함수의 하부에서 사용하는 메모리 영역이 있는지 판단하여, 메모리 영역을 제1 메모리에 할당할 수 있는지 판단하는 단계, 판단 결과, 메모리 영역을 제1 메모리에 할당할 수 없는 경우, 제2 메모리에 할당되는 소정의 크기만큼을 제1 메모리에 저장한 경우의 성능 이득과, 제1 메모리에서 사용 중인 메모리 영역의 크기만큼을 제2 메모리로 복사하고, 복원하는 비용을 비교하는 단계 및 비교 결과, 성능 이득이 큰 경우, 메모리 영역의 크기만큼을 제2 메모리로 복사하고, 메모리 영역의 크기만큼을 제1 메모리에 할당하는 단계를 포함한다.

Description

멀티 프로세서 시스템 온 칩에서의 메모리 관리 방법{Method for managing a memory in a multi processor system on chip}
본 발명의 일 실시 예는 메모리 관리 방법에 관한 것으로, 더 상세하게는 멀티 프로세서 시스템 온 칩에서의 메모리 관리 방법에 관한 것이다.
임베디드 시스템의 성능 요구치가 끊임없이 증가함에 따라 이를 만족하기 위하여 하나의 SoC(System-on-a-Chip)에 점점 더 많은 프로세서들을 집적하는 것이 불가피하게 되었다.
SoC는 한 개의 칩 상에 완전한 구동 가능한 제품, 즉 시스템이 들어있는 것을 말한다. 컴퓨터가 명령어를 처리하기 위해 필요한 모든 하드웨어 컴포넌트를 하나의 칩 상에 포함하고 있는 데 비해, SoC는 그 컴퓨터와 필요한 모든 부수적인 전자 부품들을 포함한다. 예를 들면, 통신에 사용되는 SoC에는 마이크로프로세서, DSP, 램과 롬 등이 함께 포함될 수 있다. SoC을 이용하면 일반적으로 시스템의 크기가 작아지며, 조립 과정도 단순해진다. 따라서, 듀얼(2), 쿼드(4)의 프로세서들, DSP, 램과 롬 등을 하나의 칩 상에 집적하고 있다.
한편, 이러한 멀티프로세서 시스템 온 칩(MPSoC)의 메모리 구조가 도 1에 도시되어 있다.
도 1을 참조하면, 4개의 CPU(110, 120, 130 및 140), DSP(150), RP(Reconfigurable Processor, 160), 각각의 프로세서의 로컬 SRAM(111, 121, 131, 141, 151 및 161)을 포함하는 SoC(100) 및 DRAM(170)이 도시되어 있다.
이러한 멀티 프로세서 시스템 온 칩에서는 각각의 프로세서에 속한 메모리들(111 내지 161)과 메인 메모리인 DRAM(170)으로의 액세스가 시간 지연 문제와, 전력 소비 등의 문제를 해결하는데 중요한 역할을 한다.
도 2A 내지 2C 는 도 1의 멀티 프로세서 SoC 구조에서 종래의 스크래치 패드 메모리를 할당하는 구조를 도시한 도면이다.
도 2A 내지 2C를 참조하면, 스크래치 패드 메모리(200), 메인 메모리(210) 및 태스크 A 내지 D(220, 230, 240 및 250)가 도시되어 있다.
스크래치 패드 메모리(Scratch-Pad Memory, 200)는 소프트웨어, 예를 들면 애플리케이션 및/또는 컴파일러에 의해 관리되는 고속 SRAM이다. 스크래치 패드 메모리는 데이터 및 명령어의 액세스를 최적화하기 위해 사용된다.
스크래치 패드 메모리(200)는 일반적으로 온-칩에 존재하는 데이터 메모리를 말하며, 주소 공간은 오프-칩 메모리와는 분리되어 있으나 같은 주소와 데이터 버스로 연결되어 있다. 스크래치 패드 메모리(200)에 저장되어 있는 데이터에는 빠른 액세스가 가능하나 오프-칩 메모리에 저장되어 있는 데이터는 상대적으로 많은 액세스 시간을 요구한다.
일반적인 캐시 메모리와 스크래치 패드 메모리의 큰 차이점은 스크래치 패드 메모리는 무조건 1 사이클의 액세스 시간을 보장하지만, 캐시는 캐시 미스(cache miss) 때문에 이러한 시간 보장이 힘들다. 이러한 특성 때문에 실시간 시스템에서 한계 시간을 맞추는 데 중요한 역할을 하는 데이터들을 스크래치 패드 메모리에 저장한다. 또한, 캐시 메모리의 데이터 흐름은 애플리케이션에 독립적으로 하드웨어에 의해 제어되고, 캐시 라인의 정교함에 의해 좌우되지만, 스크래치 패드 메모리는 소프트웨어가 메모리로부터 데이터를 읽거나 메모리에 데이터를 저장하는 것을 제어한다는 것이다.
메인 메모리(210)는 오프 칩 메모리이며, 일반적으로 DRAM, SDRAM 등을 포함한다. 메인 메모리(210)는 멀티 프로세서 시스템 온 칩에서 스크래치 패드 메모리(200)를 포함하는 SRAM의 하위 메모리로 사용한다.
이러한 메모리 배치 구조는 CPU에서 가까운 메모리는 용량이 작고, 매우 빠르며, 가격이 비싸지만, 이에 반하여, CPU에서 멀리 있는 메모리는 용량이 크고, 상대적으로 느리며, 가격이 저렴하기 때문이다.
또한, 스크래치 패드 메모리(200)에 대한 액세스 시간은 메인 메모리(210)의 액세스 시간에 비해 약 10 내지 1000배 정도 빠르다, 그러므로, 데이터나 명령어를 스크래치 패드 메모리(200)에서 가지고 오는 것이 전체적인 시스템 성능을 향상시킬 수 있다.
따라서, CPU가 명령어 또는 데이터를 메모리로부터 패치(fetch)할 경우에, 우선 그 명령어 또는 데이터가 스크래치 패드 메모리(200)에 있는지 확인하고, 있다면 가지고 오고, 그렇지 않을 경우에는 메인 메모리(210)에서 가지고 와야 한다.
도 2A 내지 2C는 종래의 스크래치 패드 메모리(200) 관리 방법들에 관한 것으로, 각각의 태스크들의 변수 또는 데이터들을 스크래치 패드 메모리(200)의 물리적 주소 공간에 할당하는 방법들이다.
도 2A는 스크래치 패드 메모리(200)를 정적 할당(static allocation)하는 기법을 도시한 것이다. 정적 할당은 정적으로 생성된 태스크A(220)의 변수들을 스크래치 패드 메모리(200)에 할당하고, 정적으로 생성된 태스크B(230)는 태스크 A(220)에 비하여 자주 쓰이는 것으로 좀 더 넓은 공간을 할당한다.
하지만, 이는 지역성(locality)을 반영하지 못하고, 동적으로 생성된 태스크C(240)에는 적용할 수 없거나 또는 이를 위해서 항상 공간을 할당하여야 하며, 동적으로 로딩된 태스크D(25)에는 적용하지 못하는 문제점이 있다.
여기서, 지역성이란 사용자 프로그램이 실행될 때, 프로그램 내의 모든 명령들이 균일하게 사용되지 않고, 일부 명령어들이 집중적으로 실행되는 현상을 말하며, 시간 지역성과 공간 지역성으로 구분된다. 태스크C(240)는 사용자의 선택에 의해 실행되는 것을 말하며, 태스크D(250)는 네트워크 등을 통하여 애플리케이션의 소스 코드 등을 로딩하여 수행되는 것을 말한다.
도 2B를 참조하면, 컴파일러에 기초한 동적 할당기법이 도시되어 있다. 이는 스크래치 패드 메모리(200)에서 메인 메모리(210)로 스왑 아웃하고, 메인 메모리(210)로부터 스크래치 패드 메모리(200)로 스왑 인하여 스크래치 패드 메모리(200)를 관리하는 것이다.
더 구체적인 사항은 S. Udayakumaran 등의 "Dynamic Allocation for Scratch-Pad Memory Using Compile-Time Decision" ACM Trans. Embedded Computing Systems, Vol. 5, No. 2, pp 472-511, May 2006. 에 개시되어 있다.
하지만, 이러한 방법은 태스크 별로 사용되는 메모리 공간을 고정하여 지역성을 반영하지 못하는 문제점과, 동적으로 생성되는 태스크C(240)를 위해서 항상 공간을 할당하여야 하고, 이러한 태스크들의 수가 많은 경우에는 해결책을 제시하지 못하며, 특히 동적으로 로딩되는 태스크D(250)에는 적용할 수 없다는 문제점이 있다.
도 2C는 스크래치 패드 메모리의 분할 관리 방법을 설명한다. 이는 프로파일링을 통해 컴파일러가 삽입한 코드를 기초로 동작하며, 메모리 할당부(260)가 각각의 태스크들(220, 230, 240 및 250)에서 필요한 변수 또는 데이터의 크기, 및 메모리 접근 빈도수에 따라 스크래치 패드 메모리(200)에 할당하는 것이다.
더 구체적인 사항은 O. Ozturk 등의 "Shared Scratch-Pad Memory Space Management." IEEE ISQED, 2006.에 개시되어 있다.
하지만, 이러한 방법은 적용범위가 루프를 사용해 접근하는 배열에 한정되어 범용점으로 사용할 수 없을 뿐만 아니라, 오버헤드(overhead)가 크다는 단점이 있다.
본 발명의 일 실시 예는 전술한 종래기술들의 문제점을 해결하고자 안출된 것으로, 멀티 프로세서 SoC에서 메모리, 특히 스크래치 패드 메모리를 효율적으로 관리하는 멀티 프로세서 시스템 온 칩에서의 메모리 관리 방법을 제공하는 데 목적이 있다.
또한, 동적으로 생성되는 태스크와 동적으로 로딩되는 태스크까지 효과적인 메모리 할당이 가능한 멀티 프로세서 시스템 온 칩에서의 메모리 관리 방법을 제공하는 데 다른 목적이 있다.
상기 기술적 과제를 달성하기 위한 본 발명의 일 실시 예에 따른 멀티프로세서 시스템 온 칩에서의 메모리 관리 방법은 소정의 함수의 하부에서 사용하는 메모리 영역이 있는지 판단하여, 상기 메모리 영역을 제1 메모리에 할당할 수 있는지 판단하는 단계; 상기 판단 결과 상기 메모리 영역을 상기 제1 메모리에 할당할 수 없는 경우, 제2 메모리에 할당되는 소정의 크기만큼을 상기 제1 메모리에 저장한 경우의 성능 이득과, 상기 제1 메모리에서 사용 중인 메모리 영역의 상기 크기만큼을 상기 제2 메모리로 복사하고, 복원하는 비용을 비교하는 단계; 및 상기 비교 결과 상기 이득이 큰 경우, 상기 메모리 영역의 상기 크기만큼을 상기 제2 메모리로 복사하고, 상기 메모리 영역의 상기 크기만큼을 상기 제1 메모리에 할당하는 단계를 포함한다.
본 발명의 또 다른 기술적 과제를 달성하기 위한 상기 방법을 컴퓨터에서 실행시키기 위한 프로그램을 기록한 기록매체를 포함한다.
본 발명의 일 실시 예에 따라 심볼 테이블을 참조하여 심볼에 대응하는 변수 또는 함수의 코드의 메모리 접근 빈도 수를 기초로 저장 위치를 결정하고, 결정된 저장 위치와 이전에 저장되어 있던 위치를 비교하여, 결정된 저장 위치가 다른 위치인지 판단하여 다른 위치인 경우, 결정된 저장 위치에 이전 위치에 저장된 변수 또는 함수의 코드를 복사함으로써, 메모리의 지역성을 반영하고, 한정된 메모리 자원을 효과적으로 사용할 수 있다. 또한, 동적으로 생성되는 태스크와 동적으로 로딩된 태스크에도 적용할 수 있을 뿐만 아니라, 범용적으로 사용할 수 있다.
도 1은 일반적인 멀티 프로세서 시스템 온 칩의 구조를 도시한 도면이다.
도 2A 내지 2C 는 도 1의 멀티 프로세서 SoC 구조에서 종래의 스크래치 패드 메모리를 할당하는 구조를 도시한 도면이다.
도 3은 본 발명의 일 실시 예에 따른 스크래치 패드 메모리를 관리하는 방법을 설명하기 위한 흐름도이다.
도 4는 본 발명의 다른 실시 예에 따른 스크래치 패드 메모리를 관리하는 방법을 설명하기 위한 흐름도이다.
도 5는 본 발명의 또 다른 실시 예에 따른 스크래치 패드 메모리를 관리하는 방법을 설명하기 위한 흐름도이다.
도 6은 도 5에 도시된 스크래치 패드 메모리를 관리하는 방법에 따른 메모리 사용방법을 구체적으로 도시한 도면이다.
이하, 첨부한 도면들을 참조하여 본 발명의 실시 예들을 상세히 설명한다.
도 3은 본 발명의 일 실시 예에 따른 스크래치 패드 메모리를 관리하는 방법을 설명하기 위한 흐름도이다.
단계 300에서, 심볼 테이블(symbol table)을 참조한다. 여기서, 심볼 테이블은 스크래치 패드 메모리의 일부 영역을 대체하기 위한 것으로, 특정 태스크의 변수 또는 데이터를 메모리에 할당할 때, 컴파일러에 의해 제공된다.
심볼 테이블은 {<심볼 명칭>,<주소>}의 쌍으로 구성된다. 예를 들면, {6, 0x12345678}이라는 항목이 있고, 심볼 명칭을 모아둔 섹션의 값이 'H', 'E', 'L', 'L', 'O', '\0', 'B', 'Y', 'E', '\O'라고 하면 이 섹션의 주소 5에 해당하는 곳에서부터 Null로 끝나는 문자열의 값이 BYE이기 때문에, BYE 심볼의 주소는 0x12345678가 된다.
단계 302에서, 특정 태스크의 접근 빈도 수를 고려하여 저장할 위치를 결정한다. 즉 스크래치 패드 메모리를 포함하는 상위 메모리에 저장할지, 아니면 DRAM을 포함하는 하위 메모리에 저장할지를 결정한다.
여기서, 접근 빈도 수는 특정 태스크가 메모리에 액세스하는 횟수를 의미한다. 코드가 변수 또는 함수의 위치를 구하기 위하여 심볼 테이블을 참조하도록 생성되면, 이 심볼 테이블을 참조하는 코드에서 찾고자 하는 심볼의 접근 빈도를 갱신한다.
심볼의 접근 빈도 수를 갱신하는 방법은 심볼이 접근할 때마다 1씩 증가시키고 이를 시스템 시작부터 현재까지 경과 시간으로 나누어서 구할 수 있다.
또한, 선택적으로 이전 접근 시간을 기록해 두고 이번 접근시와 시간적인 차를 활용하여 구할 수 있다. 예를 들면, 시간 차가 크다면 이전에 저장된 접근 빈도를 많이 낮추고, 그렇지 않은 경우 조금 낮추는 방법을 사용할 수 있다. 즉 시간 차가 클 경우에는 0과 1 사이에 0에 가까운 수를 곱해서 접근 빈도를 갱신하고, 시간 차가 작다면 0과 1 사이에 1에 가까운 수를 곱해서 계산할 수 있다.
여기서, 상위 메모리는 스크래치 패드 메모리를 포함하며, 액세스가 빠른 메모리 또는 제1 레벨의 메모리(First Level Memory)를 포함하는 의미이며, 하위 메모리는 DRAM을 포함하며, 느린 메모리 또는 제2 레벨 메모리(Second Level Memory)를 포함한다. 또한, 메모리 레벨은 2개 이상으로 확장가능하다.
단계 304에서는, 단계 302에서 결정된 변수 또는 데이터의 저장 위치가 이전에 저장된 위치와 비교해서 새로운 위치인지를 판단한다. 예를 들면, 이전에 저장된 위치는 DRAM이었는데, 단계 302에서 결정된 저장 위치는 스크래치 패드 메모리인 경우 또는 반대의 경우를 의미한다.
특정 함수 또는 변수를 저장할 위치가 이전에 저장되어 있던 위치와 다른 경우에, 단계 306에서, 새로운 메모리에서 복사할 위치를 확보하고, 단계 308에서, 새로운 위치에 복사한다.
여기서, 복사는 특정 함수 또는 변수를 저장할 위치가 이전에 저장되어 있던 위치와 다른 경우에 새로운 위치로 이를 옮기는 것을 의미하며, 새로운 위치에 저장할 물리적 공간이 부족한 경우에는 기존의 메모리 블록을 축출(eviction)한다.
함수 코드의 경우, 새로운 위치의 메모리가 이전 메모리보다 상위 메모리인 경우, 예를 들면 이전에는 DRAM이나 새로운 위치는 스크래치 패드 메모리인 경우에는 새로운 위치로 이전 메모리에 있던 코드를 복사하고 이전 메모리의 코드는 삭제하거나 그대로 유지할 수 있다.
반대로, 새로운 메모리가 이전 메모리보다 하위라면 새로운 위치에 코드를 복사하고 이전 메모리를 삭제하며, 코드의 복사 후에는 코드 명령어 내에서 사용하는 상대 주소, 예를 들면 브랜치 명령어의 타켓 주소 등을 변경해 주어야 한다.
변수의 경우, 새로운 위치로 이전 위치의 데이터를 복사하고 이전 위치의 데이터는 데이터의 특성, 예를 들면 Read Only 여부에 따라 삭제 유지 여부를 결정할 수 있다. 변수의 경우 포인터 변수인 경우에는 복사 후의 값을 새로운 위치와 이전 위치 사이의 주소 차만큼 조정할 필요가 있다.
그리고 단계 310에서, 이전에 참조했던 심볼 테이블을 갱신한다. 이전의 심볼의 주소를 새로운 위치의 메모리의 주소로 갱신한다.
도 4는 본 발명의 다른 실시 예에 따른 스크래치 패드 메모리를 관리하는 방법을 설명하기 위한 흐름도이다.
도 4를 참조하면, 도 3과 비교하여, 크리티컬 섹션(Critical section)을 설정/해제하는 루틴이 추가된다. 여기서 크리티컬 섹션은 하나 이상의 태스크 등에서 공통으로 접근하는 데이터 영역을 공유 영역이라 하며, 이 공유 영역을 접근하는 루틴을 말한다.
단계 400에서, 심볼 테이블(symbol table)을 참조한다. 단계 402에서, 크리티컬 섹션을 설정한다. 이는 심볼 테이블, 빈도 수, 원래 위치 및 새로운 위치를 확보하였음을 유지하는 메모리 관리자 메타데이터 등이 공유 데이터이므로, 이 공유 데이터의 일관성을 유지하기 위해서 설정된다.
크리티컬 섹션의 설정은, 예를 들면 인터럽트를 끄거나 스케줄러를 끄는 방식으로 코드 간 간섭을 해결할 수 있다. 또한, 세마포어 또는 뮤텍스를 이용하여 설정할 수 있다.
단계 404에서, 특정 태스크의 접근 빈도 수를 고려하여 저장할 위치를 결정한다. 즉 스크래치 패드 메모리를 포함하는 상위 메모리에 저장할지, 아니면 DRAM을 포함하는 하위 메모리에 저장할지를 결정한다.
단계 406에서, 단계 404에서 결정된 변수 또는 데이터의 저장 위치가 이전에 저장된 위치와 비교해서 새로운 위치인지를 판단한다.
특정 함수 또는 변수를 저장할 위치를 이전에 저장되어 있던 위치와 다른 경우에, 단계 408에서, 새로운 메모리에서 복사할 위치를 확보하고, 단계 410에서, 새로운 위치에 복사한다.
그리고 단계 412에서, 이전에 참조했던 심볼 테이블을 갱신한다. 이전의 심볼의 주소를 새로운 위치의 메모리의 주소로 갱신한다.
마지막으로, 단계 414에서 설정된 크리티컬 섹션을 해제한다.
도 5는 본 발명의 또 다른 실시 예에 따른 스크래치 패드 메모리를 관리하는 방법을 설명하기 위한 흐름도이다.
단계 500에서, 함수의 시작 시점에 컴파일러 분석을 수행한다. 컴파일러를 통해, 예를 들면 제어 흐름(control flow) 분석 등을 이용할 수 있다.
단계 502에서, 단계 500에서의 컴파일러 분석을 통해 해당 함수의 하부에서만 사용하는 메모리가 있는지 여부를 판단한다. 하부에서만 사용하는 메모리 영역은 프로그램의 실제 코드가 저장되어 있는 영역인 텍스트 영역, 전역변수 등의 데이터가 저장되는 영역인 데이터 영역, 로컬변수, 함수에 호출에 관련된 정보, 임시데이터가 저장되는 영역인 스택 영역, 동적 메모리 할당에 사용되는 영역인 힙 영역을 포함한다.
바람직하게, 하부에서만 사용하는 메모리 영역은 스택(stack) 영역 또는 힙(heap) 영역을 포함하며, 더 바람직하게, 스택 영역을 포함한다.
스택 영역은 로컬 변수, 함수에 호출에 관련된 정보, 또는 임시 데이터가 저장되는 영역으로, 메모리 블록 내에서 할당된 변수 등이 들어가 처리해야 할 요청을 저장하는 공간을 말하며, 새로운 요청이 들어오면 이전의 것을 밑으로 내린다.
힙 영역은 동적 메모리 할당에 사용되는 영역으로 프로그램이 실행될 때까지는 알 수 없는 가변적인 량만큼의 데이터를 저장하기 위해, 프로그램의 프로세스가 사용할 수 있도록 미리 예약되어 있는 메모리 영역이다.
단계 502에서의 판단 결과, 함수의 하부에서만 사용하는 메모리가 있는 경우에는, 단계 504에서, 이를 스크래치 패드 메모리에 할당할 수 있는지 여부를 판단한다. 즉, 스크래치 패드 메모리에 할당할지 여부에 대한 의사 결정을 한다.
구체적인 판단은 스크래치 패드 메모리의 여유 공간과 해당 함수의 하부에서 사용하는 메모리의 크기를 고려한다.
예를 들면, 스크래치 패드 메모리의 남은 공간이 해당 함수의 하부에서만 사용하는 메모리의 크기에 비해 커야 하며, 스크래치 패드 메모리의 남은 공간은 이 함수의 호출시에 메모리의 남아 있는 물리 공간에서 해당 함수가 리프(Leaf) 함수, 즉 다른 함수를 호출하지 않는 함수가 아닌 경우에는, 해당 함수에서만 사용하는 메모리가 소멸하기 이전에 호출되는 이의 자식 함수들에 의해서 반드시 사용되어야 하는 메모리 공간까지 포함하는 것보다 커야 한다.
단계 504에서의 판단 결과, 스크래치 패드 메모리의 여유 공간이 해당 함수의 하부에서만 사용하는 메모리의 크기보다 큰 경우에는 단계 505로 진행하여, 스택 또는 힙 영역을 스크래치 패드 메모리에 할당한다.
단계 504에서의 판단 결과, 스크래치 패드 메모리의 여유 공간이 해당 함수의 하부에서만 사용하는 메모리의 크기보다 작은 경우, 즉 스크래치 패드 메모리에 할당할 수 없는 경우에는, 단계 506으로 진행하여 알파 값과 베타 값을 계산한다.
여기서, 알파(α)는 하위 메모리, 즉 DRAM에 할당되는 메모리 중에서 특정 크기(S)만큼을 스크래치 패드 메모리에 저장했을 때의 성능 이득이다. 여기서, 특정 크기(S)는 다음 수학식 1에 의해 계산될 수 있다.
[수학식 1]
S = min(S1, S2)
여기서, S1은 DRAM에 할당되는 메모리의 크기이고, S2는 기 사용중인 스택의 크기이다.
또한, 성능 이득은 메모리 접근 횟수와 메모리의 성능 차이를 곱하여 얻을 수 있으며, 성능 차이는 DRAM 액세스 시간에서 스크래치 패드 메모리 액세스 시간을 뺀 값이다.
베타(β)는 사용중인 스택 하부의 S만큼을 DRAM으로 복사하고 복원하는 데 들이는 비용이다. 여기서 S는 상기 수학식 1에 의해 계산된 크기이며, 비용은 메모리를 옮기는 데 들이는 시스템 자원 소모, 시간 등을 포함하는 의미이다.
단계 508에서, 단계 506에서 계산된 알파와 베타를 비교하여 알파가 베타보다 작은 경우에는 단계 509로 진행하여 해당 함수의 하부에서만 사용하는 메모리를 DRAM에 할당한다.
단계 508에서, 단계 506에서 계산된 알파와 베타를 비교하여 알파가 베타보다 큰 경우에는, 단계 510에서, 스택의 최하단 S, 즉 스택 중에서 해당 함수의 하부에서 사용하지 않는 크기 만큼을 메모리로 복사하고, 즉 DRAM에 할당할 메모리 중에서 S만큼을 스크래치 패드 메모리에 할당하여 함수를 수행하고, 복사한 스택을 사용하는 함수로 리턴하기 이전에 복사한 스택을 복구한다.
도 6은 도 5에 도시된 스크래치 패드 메모리를 관리하는 방법에 따른 복사(copy)/복구(restore)를 구체적으로 도시한 도면이다.
도 6을 참조하여, 함수 A, 함수 B, 함수 C, 함수 B 및 함수 A를 순차적으로 수행하는 경우에, 상위 메모리인 스크래치 패드 메모리(600, 620, 640, 660 및 680)에 저장되는 스택 영역과 힙 영역의 변화, 즉 하위 메모리인 DRAM(610, 630, 650, 670 및 690)으로의 복사 및 복구를 설명한다.
먼저, 함수 A를 수행하면서, 함수 A의 끝 부분에 추가 검색 루틴을 추가하여 함수 A의 하부에서만 사용하는 메모리, 즉 스택(a) 또는 힙(a')이 존재하는지 판단하여, 스택 영역 또는 힙 영역이 존재하는 경우, 이를 스크래치 패드 메모리(600)에 할당할 수 있는지 결정한다.
여기서, 스크래치 패드 메모리에 할당할 수 있는지 여부의 결정은 도 5에 도시된 단계 504에서의 판단 결과에 따라 알파 값과 베타 값을 계산하고, 계산된 알파와 베타를 비교하여 알파가 베타보다 큰 경우에 스택 영역(a)을 DRAM(630)으로 복사한다.
그리고, 현재 수행 중인 함수 B의 스크래치 패드 메모리(620)에는 스택(b)과 힙(b')이 저장되어 있고, DRAM(630)에는 함수의 A의 힙(a')과 복사된 스택(a)이 저장되어 있다. 도면에서는 함수 B의 힙(b')이 스크래치 패드 메모리(620)에 저장되어 있지만, DRAM(630)에 저장될 수 있음은 물론이다.
그리고 함수 C가 수행되면, 스크래치 패드 메모리(640)에는 기존에 저장되어 있던 함수 B의 스택 영역(b)과 힙 영역(b'), 및 함수 C의 스택 영역(c)과 힙 영역(c')이 저장되어 있고, DRAM(650)에는 함수 A의 힙 영역(a')과 스택 영역(a)이 저장되어 있다. 여기서, 함수 C가 수행될 때, 함수 B의 스택(b)과 힙(b')이 스크래치 패드 메모리(640)에 저장되어 있는 것으로 도시되었으나, 삭제될 수 있음은 물론이다.
다시, 함수 B로 돌아오면, 함수 C의 스택(c)과 힙(c')이 삭제된다. 그리고, 함수 B의 끝 부분에 함수 A의 스택(a')을 복구하는 루틴이 추가된다.
함수 A돌 돌아오면, 함수 B의 스택(b)과 힙(c')이 스크래치 패드 메모리(680)에서 삭제되고, 함수 A의 스택(a)이 DRAM(690)에서 스크래치 패드 메모리(680)로 복구된다.
본 발명은 또한 컴퓨터로 읽을 수 있는 기록매체에 컴퓨터가 읽을 수 있는 코드로서 구현하는 것이 가능하다. 컴퓨터가 읽을 수 있는 기록매체는 컴퓨터 시스템에 의하여 읽혀질 수 있는 데이터가 저장되는 모든 종류의 기록장치를 포함한다. 컴퓨터가 읽을 수 있는 기록매체의 예로는 ROM, RAM, CD-ROM, 자기 테이프, 플로피 디스크, 광 데이터 저장장치 등이 있으며, 또한 캐리어 웨이브(예를 들어 인터넷을 통한 전송)의 형태로 구현되는 것도 포함한다.
이상 본 발명의 바람직한 실시예들을 기초로 설명되었지만, 당업자들은 본 발명이 속하는 기술분야의 기술적 사상이나 필수적 특징을 변경하지 않고서 다른 구체적인 형태로 실시될 수 있다는 것을 이해할 수 있을 것이다. 그러므로 이상에서 기술한 실시예들은 모든 면에서 예시적인 것이며 한정적인 것이 아닌 것으로서 이해되어야 한다. 본 발명의 범위는 상기 상세한 설명보다는 후술하는 특허청구범위에 의하여 한정되며, 특허청구범위의 의미 및 범위 그리고 그 등가 개념으로부터 도출되는 모든 변경 또는 변형된 형태가 본 발명의 범위에 포함되는 것으로 해석되어야 한다.

Claims (10)

  1. 소정의 함수의 하부에서 사용하는 메모리 영역이 있는지 판단하여, 상기 메모리 영역을 제1 메모리에 할당할 수 있는지 판단하는 단계;
    상기 판단 결과, 상기 메모리 영역을 상기 제1 메모리에 할당할 수 없는 경우, 제2 메모리에 할당되는 소정의 크기만큼을 상기 제1 메모리에 저장한 경우의 성능 이득과, 상기 제1 메모리에서 사용 중인 메모리 영역의 상기 크기만큼을 상기 제2 메모리로 복사하고, 복원하는 비용을 비교하는 단계; 및
    상기 비교 결과, 상기 성능 이득이 큰 경우, 상기 메모리 영역의 상기 크기만큼을 상기 제2 메모리로 복사하고, 상기 메모리 영역의 상기 크기만큼을 상기 제1 메모리에 할당하는 단계를 포함하는 멀티 프로세서 시스템 온 칩에서의 메모리 관리 방법.
  2. 제 1 항에 있어서,
    상기 비교 단계는,
    상기 제2 메모리에 할당되는 메모리 영역의 크기와 상기 제1 메모리에서 기 사용중인 메모리 영역의 크기를 비교하는 단계를 더 포함하고,
    상기 크기는,
    상기 제2 메모리에 할당되는 메모리 영역의 크기와 상기 제1 메모리에서 기 사용중인 메모리 영역의 크기 중 더 작은 크기인 것을 특징으로 하는 멀티 프로세서 시스템 온 칩에서의 메모리 관리 방법.
  3. 제 1 항에 있어서,
    상기 비교 단계에서,
    상기 성능 이득은,
    상기 함수의 메모리 접근 횟수와, 상기 제2 메모리의 액세스 시간과 상기 제1 메모리의 액세스 시간의 차이를 기초로 계산하는 것을 특징으로 하는 멀티 프로세서 시스템 온 칩에서의 메모리 관리 방법.
  4. 제 1 항에 있어서,
    상기 판단 단계에서,
    상기 제1 메모리의 여유 공간 및 상기 함수의 하부에서만 사용하는 메모리 영역의 크기를 비교하여 결정하는 것을 특징으로 하는 멀티 프로세서 시스템 온 칩에서의 메모리 관리 방법.
  5. 제 1 항에 있어서,
    상기 판단 단계는,
    상기 함수의 시작 시점에 컴파일러 분석을 통해 상기 함수의 하부에서 사용하는 메모리 영역이 있는지 판단하는 것을 특징으로 하는 멀티 프로세서 시스템 온 칩에서의 메모리 관리 방법.
  6. 제 1 항에 있어서,
    상기 할당 단계에서,
    상기 함수가 다시 수행되기 전에 상기 복사한 메모리 영역을 상기 제1 메모리 영역으로 복구하는 것을 특징으로 하는 멀티 프로세서 시스템 온 칩에서의 메모리 관리 방법.
  7. 제 1 항에 있어서,
    상기 메모리 영역은 상기 함수의 스택 영역을 포함하는 것을 특징으로 하는 멀티 프로세서 시스템 온 칩에서의 메모리 관리 방법.
  8. 제 1 항에 있어서,
    상기 제1 메모리는 멀티 프로세서 시스템 온 칩(Multi Processor System on Chip) 내부에 존재하는 SRAM인 것을 특징으로 하는 멀티 프로세서 시스템 온 칩에서의 메모리 관리 방법.
  9. 제 8 항에 있어서,
    상기 SRAM은,
    스크래치 패드 메모리를 포함하는 것을 특징으로 하는 멀티 프로세서 시스템 온 칩에서의 메모리 관리 방법.
  10. 제 1 항 내지 제 9 항 중 어느 한 항에 따른 방법을 컴퓨터에서 실행시키기 위한 프로그램을 기록한 기록매체.
KR1020130100570A 2013-08-23 2013-08-23 멀티 프로세서 시스템 온 칩에서의 메모리 관리 방법 KR101334189B1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020130100570A KR101334189B1 (ko) 2013-08-23 2013-08-23 멀티 프로세서 시스템 온 칩에서의 메모리 관리 방법

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020130100570A KR101334189B1 (ko) 2013-08-23 2013-08-23 멀티 프로세서 시스템 온 칩에서의 메모리 관리 방법

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
KR1020070006298A Division KR101334176B1 (ko) 2007-01-19 2007-01-19 멀티 프로세서 시스템 온 칩에서의 메모리 관리 방법

Publications (2)

Publication Number Publication Date
KR20130114023A true KR20130114023A (ko) 2013-10-16
KR101334189B1 KR101334189B1 (ko) 2013-11-28

Family

ID=49634304

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020130100570A KR101334189B1 (ko) 2013-08-23 2013-08-23 멀티 프로세서 시스템 온 칩에서의 메모리 관리 방법

Country Status (1)

Country Link
KR (1) KR101334189B1 (ko)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20150114444A (ko) * 2014-04-01 2015-10-12 삼성전자주식회사 실시간 운영 체제에서 스택 메모리 관리를 제공하는 방법 및 시스템
KR20220055217A (ko) * 2020-10-26 2022-05-03 주식회사 에이직랜드 온칩 시스템의 데이터 관리 장치 및 방법

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7367024B2 (en) 2004-09-21 2008-04-29 University Of Maryland Compiler-driven dynamic memory allocation methodology for scratch-pad based embedded systems

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20150114444A (ko) * 2014-04-01 2015-10-12 삼성전자주식회사 실시간 운영 체제에서 스택 메모리 관리를 제공하는 방법 및 시스템
KR20220055217A (ko) * 2020-10-26 2022-05-03 주식회사 에이직랜드 온칩 시스템의 데이터 관리 장치 및 방법

Also Published As

Publication number Publication date
KR101334189B1 (ko) 2013-11-28

Similar Documents

Publication Publication Date Title
KR101334176B1 (ko) 멀티 프로세서 시스템 온 칩에서의 메모리 관리 방법
US10999214B2 (en) Secure memory with restricted access by processors
CN105074666B (zh) 执行在具有不同指令集架构的处理器上的操作系统
US10949200B2 (en) Methods and apparatus for executing data-dependent threads in parallel
US8214816B2 (en) Compiler implemented software cache in which non-aliased explicitly fetched data are excluded
US20160328169A1 (en) Managed energy-efficient hybrid main memory systems
US10031697B2 (en) Random-access disjoint concurrent sparse writes to heterogeneous buffers
JP2010532530A (ja) メモリトランザクションのグループ化
Zhao et al. Dynamic memory optimization using pool allocation and prefetching
US8954969B2 (en) File system object node management
KR20140134523A (ko) 데이터를 기반으로 전력을 관리하는 프로세싱 장치 및 그 장치를 이용한 방법
Guo et al. Mira: A program-behavior-guided far memory system
KR101334189B1 (ko) 멀티 프로세서 시스템 온 칩에서의 메모리 관리 방법
Memarzia et al. The art of efficient in-memory query processing on NUMA systems: a systematic approach
US9298630B2 (en) Optimizing memory bandwidth consumption using data splitting with software caching
US20140304485A1 (en) Embedded memory management scheme for real-time applications
US20090320036A1 (en) File System Object Node Management
Shrivastava et al. Automatic management of Software Programmable Memories in Many‐core Architectures
CN115481072A (zh) 核间数据传输方法、多核芯片及机器可读存储介质
Shoushtari et al. Shave-ice: Sharing distributed virtualized spms in many-core embedded systems
Avni et al. Abort free semantictm by dependency aware scheduling of transactional instructions
Memarzia et al. Toward Efficient In-memory Data Analytics on NUMA Systems
CN114428653B (zh) 使用不同编译设置的代码的即时jit编译实例
Jatala et al. Scratchpad sharing in GPUs
Zhang et al. Locality‐protected cache allocation scheme with low overhead on GPUs

Legal Events

Date Code Title Description
A107 Divisional application of patent
A201 Request for examination
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20161018

Year of fee payment: 4

FPAY Annual fee payment

Payment date: 20171018

Year of fee payment: 5