KR101638064B1 - 캐시 제거 통지를 디렉토리로 수집 - Google Patents

Abstract

여기에 일반적으로 설명되는 기술은 캐시 제거 통지의 디렉토리로의 수집에 관련된다. 일부 예시적인 기술은 적어도 하나의 캐시 메모리의 복수의 블록 주소로부터의 복수의 블록의 제거를 반영하도록 수집 테이블을 갱신하는데에 이용될 수 있다. 수집 테이블에서 반영된 복수의 블록의 제거를 특정하는 수집 메시지가 생성될 수 있다. 수집 메시지는 디렉토리로 전송될 수 있다. 디렉토리는 수집 메시지를 파스할 수 있고 수집 메시지에서 특정된 캐시 메모리로부터의 제거를 반영하도록 복수의 디렉토리 엔트리를 갱신할 수 있다.

Description

캐시 제거 통지를 디렉토리로 수집 {AGGREGATING CACHE EVICTION NOTIFICATIONS TO A DIRECTORY}

여기에서 달리 명시되지 않는 한, 본 섹션에서 설명되는 내용은 본 출원에서 청구범위에 대한 종래 기술이 아니며, 본 섹션에 포함함으로써 선행 기술로 인정되지 않는다.

많은 컴퓨팅 장치는 멀티코어 칩(multicore chip)을 이용하여 운영 체제 및/또는 애플리케이션 프로그램에 의해 제공되는 다양한 명령어를 실행한다. 지속적인 기술 스케일링에 따라, 하나의 멀티코어 칩에 집적될 수 있는 프로세서 코어의 수는 무어의 법칙(Moore's Law)에 의해 설명되는 경향을 계속하여 따른다. 멀티코어 기술은, 누설 전류(leakage current)로 인해 발생되는 정적 전력 소비(static power consumption)를 기하급수적으로(exponentially) 증가시키지 않으면서 문턱 전압(threshold voltage)이 더 이상 축소(scaled down)될 수 없는 시대에 들어갔다. 이는 칩의 증가하는 부분이 전혀 온으로 작동(powered-on)될 수 없거나 완전한 주파수에서 작동될 수 없는, "파워 월(power wall)", "유틸리티 월(utility wall)" 또는 "다크 실리콘(dark silicon)"으로 불리는 현상을 야기한다. 따라서, 미래의 멀티코어 칩의 성능을 개선하기 위한 길은 에너지 효율을 개선하는 것이다.

여기에서 설명되는 기술은 일반적으로 캐시 제거 통지(cache eviction notification)의 디렉토리(directory)로의 수집(aggregation)에 관한 것이다. 설명된 기술은 시스템, 방법, 장치, 및 컴퓨터 판독 가능 매체를 포함하나 이에 한정되지 않는 많은 방식으로 구현될 수 있다.

멀티코어 칩에서 캐시 제거 통지를 디렉토리로 수집하는 일부 예시적인 방법이 설명된다. 예시적인 방법은 적어도 하나의 캐시 메모리의 복수의 블록 주소로부터 복수의 블록의 제거를 반영하도록 수집 테이블(aggregation table)을 갱신(update)할 수 있다. 예시적인 방법은 수집 테이블에 반영된 복수의 블록의 제거를 특정하도록 구성되는 수집 메시지를 생성할 수 있다. 예시적인 방법은 수집 메시지를 디렉토리로 전송할 수 있다. 디렉토리는 수집 메시지를 파스(parse)하고 수집 메시지에서 특정된 캐시 메모리로부터의 제거를 반영하도록 복수의 디렉토리 엔트리(entry)를 갱신하도록 구성될 수 있다.

복수의 코어를 포함하는 일부 예시적인 멀티코어 칩이 설명된다. 적어도 하나의 캐시 메모리는 복수의 코어에 결합될 수 있다. 디렉토리 및 디렉토리 컨트롤러가 디렉토리에 결합될 수 있다. 수집 테이블은 복수의 엔트리를 포함할 수 있다. 제어 논리(control logic)는 캐시 메모리의 복수의 블록 주소로부터 복수의 블록의 제거를 반영하도록 수집 테이블을 갱신하도록 구성될 수 있다. 제어 논리는 또한 수집 메시지를 생성하도록 구성될 수 있으며, 메시지는 수집 테이블에 반영된 복수의 블록의 제거를 특정한다. 제어 논리는 디렉토리 컨트롤러에 수집 메시지를 전송하도록 더 구성될 수 있다. 디렉토리 컨트롤러는 수집 메시지를 파스하고 수집 메시지에서 특정된 적어도 하나의 캐시 메모리로부터의 제거를 반영하도록 디렉토리 내 복수의 디렉토리 엔트리를 갱신하도록 구성될 수 있다.

컴퓨터에 의해 실행되는 경우 컴퓨터가 하나 이상의 동작을 수행하도록 하는 저장된 컴퓨터 실행 가능 명령어를 포함할 수 있는 일부 예시적인 컴퓨터 판독 가능 매체가 설명된다. 일부 예시적인 동작은 멀티코어 칩에서 캐시 메모리의 제1 복수의 연속적인(sequential) 블록 주소로부터 제1 복수의 깨끗한 블록(clean block)의 제1 제거의 검출을 포함할 수 있다. 예시적인 동작은 캐시 메모리의 제2 복수의 연속적인 블록 주소로부터 제2 복수의 깨끗한 블록의 제2 제거의 검출을 포함할 수 있다. 예시적인 동작은 제1 복수의 깨끗한 블록의 제1 제거를 반영하도록 멀티코어 칩 내 수집 테이블의 제1 엔트리의 갱신을 포함할 수 있다. 예시적인 동작은 제2 복수의 깨끗한 블록의 제2 제거를 반영하도록 멀티코어 칩 내 수집 테이블의 제2 엔트리의 갱신을 포함할 수 있다. 제1 엔트리는 제1 복수의 연속적인 블록 주소에 대응할 수 있다. 제2 엔트리는 제2 복수의 연속적인 블록 주소에 대응할 수 있다. 제어 논리는 또한 수집 테이블의 제1 엔트리에 반영된 제1 복수의 깨끗한 블록의 제1 제거를 특정하도록 구성되는 제1 수집 메시지를 생성하고 수집 테이블의 제2 엔트리에 반영된 제2 복수의 깨끗한 블록의 제2 제거를 특정하도록 구성되는 제2 수집 메시지를 생성하도록 구성될 수 있다. 제어 논리는 또한 제1 수집 메시지와 제2 수집 메시지를 멀티코어 칩 내 디렉토리에 결합되는 디렉토리 컨트롤러로 전송하도록 구성될 수 있다. 디렉토리 컨트롤러는 제1 수집 메시지와 제2 수집 메시지를 파스하고, 제1 수집 메시지에 특정된 캐시 메모리로부터의 제1 제거를 반영하도록 디렉토리 내 제1 복수의 디렉토리 엔트리를 갱신하며, 제2 수집 메시지에 특정된 캐시 메모리로부터의 제2 제거를 반영하도록 디렉토리 내 제2 복수의 디렉토리 엔트리를 갱신하도록 구성될 수 있다.

캐시 제거를 처리(handle)하는 일부 예시적인 방법이 설명된다. 예시적인 방법은 블록이 캐시 메모리로부터 제거될 것이라고 결정할 수 있다. 예시적인 방법은 블록이 오염된 블록(dirty block)인지 여부를 결정할 수 있다. 예시적인 방법은 블록이 오염된 블록이라고 결정하는 것에 응답하여 오염된 블록으로서 블록의 제거를 캐시 일관성 디렉토리(cache coherence directory)에 통지할 수 있다. 예시적인 방법은 블록이 오염된 블록이 아니라고 결정하는 것에 응답하여 수집 테이블이 블록의 블록 주소에 대응하는 엔트리를 포함하는지 여부를 결정할 수 있다. 예시적인 방법은 수집 테이블이 블록의 블록 주소에 대응하는 엔트리를 포함하지 않는다고 결정하는 것에 응답하여, 블록의 블록 주소에 대응하는 수집 테이블 내 엔트리를 생성할 수 있고 깨끗한 블록으로서 캐시 메모리로부터 블록의 제거를 반영하도록 엔트리를 갱신할 수 있다. 예시적인 방법은 수집 테이블이 블록의 블록 주소에 대응하는 엔트리를 포함한다고 결정하는 것에 응답하여, 깨끗한 블록으로서 캐시 메모리로부터 블록의 제거를 반영하도록 엔트리를 갱신할 수 있다.

이상의 요약은 단지 예시적인 것으로서 어떠한 방식으로든 제한적으로 의도된 것이 아니다. 이하의 상세한 설명과 도면을 참조함으로써, 위에서 설명된 예시적인 양태들, 실시예들 및 특징들에 더하여, 추가적인 양태들, 실시예들 및 특징들이 명확해질 것이다.

본 개시의 전술한 특징들 및 다른 특징들은 첨부 도면과 함께, 다음의 상세한 설명 및 첨부된 청구범위로부터 더욱 명확해질 것이다. 이들 도면은 본 개시에 따른 단지 몇 개의 실시예들을 묘사할 뿐이고, 따라서 그 범위를 제한하는 것으로 간주되어서는 안될 것임을 이해하면서, 본 개시는 첨부 도면을 참조하여 더 구체적이고 상세하게 설명될 것이다.
도 1은 예시적인 멀티코어 칩의 양태를 도시하는 기능 블록도이고,
도 2는 전통적인 디렉토리 프로토콜에서의 블록당 제거 통지 메시지, 비트맵(bitmap) 포맷의 수집된 제거 통지 메시지, 및 포인터(pointer) 포맷의 수집된 제거 통지 메시지의 사이즈 사이의 예시적인 비교를 도시하는 표이고,
도 3은 메시지 수집 유닛이 제거 통지를 디렉토리에 수집하는데에 이용되는 멀티코어 칩의 멀티코어 칩 노드(node)의 태양을 도시하는 기능 블록도이고,
도 4는 캐시 제거 통지를 디렉토리에 수집하도록 적응되는 예시적인 프로세스를 도시하는 흐름도이고,
도 5는 캐시 제거를 처리하도록 적응되는 예시적인 프로세스를 도시하는 흐름도이고,
도 6은 수집 제거 통지 메시지를 생성하도록 적응되는 예시적인 프로세스를 도시하는 흐름도이고,
도 7은 수집 제거 통지 메시지를 선택하도록 적응되는 예시적인 프로세스를 도시하는 흐름도이고,
도 8은 전통적인 디렉토리 프로토콜을 이용하는 트래픽, 비트맵 포맷으로의 수집을 이용하는 트래픽, 및 포인터 포맷으로의 수집을 이용하는 트래픽의 예시적인 비교를 도시하는 그래프이고,
도 9는 군집 개수 함수(population count function)의 예시적인 샘플링(sampling)을 도시하는 도해이고,
도 10은 비트맵 포맷을 사용할지 포인터 포맷을 사용할지 결정하는데에 사용하기 위한 예시적인 샘플 계산을 도시하는 표이고,
도 11은 특정 상황에서 어떠한 수집 입도(granularity) 단위가 가장 트래픽을 보존하는지 결정하는데에 사용하기 위한 예시적인 샘플 계산을 도시하는 표이고,
도 12는 수집 입도 단위를 결정하도록 적응되는 예시적인 프로세스를 도시하는 흐름도이고,
도 13은 예시적인 컴퓨팅 장치를 위한 컴퓨터 하드웨어 아키텍쳐를 도시하는 블록도이고,
도 14는 컴퓨팅 장치 상에서 컴퓨터 프로세스를 실행하기 위한 컴퓨터 프로그램을 포함하는 컴퓨터 프로그램 제품을 도시하는 개략도이며,
모두 여기에서 설명되는 적어도 일부 실시예에 따라 배열된다.

이하의 상세한 설명에서, 여기의 일부를 이루는 첨부 도면에 대한 참조가 이루어진다. 문맥에서 달리 지시하고 있지 않은 한, 도면에서 유사한 부호는 통상적으로 유사한 컴포넌트를 나타낸다. 상세한 설명과 도면에서 설명되는 예시적인 실시예들은 제한적으로 여겨지지 않는다. 본 개시에서 제시되는 대상의 범위 또는 사상에서 벗어나지 않으면서 다른 실시예가 이용될 수 있고 다른 변경이 이루어질 수 있다. 여기에서 일반적으로 설명되고 도면에 도시되는 본 개시의 양태들이 다양한 다른 구성들로 배열, 대체, 조합, 분리 및 설계될 수 있음과 이 모두가 여기에서 명시적으로 고려됨이 기꺼이 이해될 것이다.

멀티코어 칩의 동작에 있어서 전력 소비의 주요한 근원 중 하나는 캐시 일관성 프로토콜(cache coherence protocol)의 구현이다. 캐시 일관성 프로토콜은 방송 및 스누핑 프로토콜(broadcast and snooping protocol)을 이용할 수 있거나, 디렉토리 프로토콜(directory protocol)을 이용할 수 있다. 이러한 프로토콜은 모두 코어의 수가 증가함에 따라 전력 소비의 면에서 초선형으로(superlinearly) 크기 변경할 수 있다. 방송 프로토콜은 임의의 코어에 의해 이루어진 각각의 요청에 대해 스누핑 및 태그 체킹(tag checking)을 이용 또는 요구할 수 있다. 그 결과, 방송 프로토콜에 대한 전력 소비는 코어의 수에 따라 2차로(quadratically) 증가할 수 있다. 한편, 디렉토리 프로토콜은 방송에 의존하지 않기 때문에 디렉토리 프로토콜은 트래픽을 상당히 감소시킬 수 있다. 따라서, 디렉토리 프로토콜에서의 트래픽은 코어의 수의 증가에 따라 상대적으로 선형으로 유지될 수 있다. 그러나, 디렉토리 프로토콜 트래픽은 네트워크의 사이즈가 증가함에 따라 더 긴 거리를 이동하여야 할 수 있고, 디렉토리 사이즈 오버헤드(overhead)가 코어의 수에 따라 2차로 증가할 수 있다.

캐시 일관성 프로토콜의 구현에 의하여 소비되는 전력은 멀티코어 칩의 전체 전력 예산(power budget)의 큰 부분을 소비할 수 있다. 불행히도 제한된 또는 미리 정해진 전력 예산은 데이터 이동 및 데이터 일관성(data coherence)을 관리하기 위해 이용되는 전력이 증가할수록 코어에서의 계산을 위하여 이용가능한 전력이 감소됨을 시사할 수 있다. 결과적으로, 멀티코어 칩에서의 성능을 개선하는 것은 계산이 아닌 활동에 대한 전력 소비를 감소시키는 것에 달려있을 수 있다. 따라서, 전력 소비를 감소시키기 위하여 일관성 프로토콜 호출(invocation) 및 트래픽은 최소로 유지되어야 한다.

전통적인 디렉토리 기반 캐시 일관성 프로토콜의 문제 중 하나는 디렉토리 내의 오래된(stale) 정보이다. 캐시가 특정 메모리 블록의 사본을 유지하는 최신의 정보를 하나 이상의 디렉토리 엔트리가 가지고 있지 않은 경우 디렉토리 내 정보가 오래된 것으로 간주될 수 있다. 더 구체적으로, 캐시가 메모리 블록을 제거한 경우에도 디렉토리의 공유 벡터 필드(sharing vector field)가 캐시에 의해 저장된 메모리 블록을 가리킬 수 있다.

오래된 정보의 일부 문제는 깨끗한(예컨대, 변경되지 않은) 캐시 블록이 캐시로부터 조용히(예컨대, 디렉토리에 통지하지 않고) 제거되는 경우 발생할 수 있다. 캐시로부터 제거되는 대부분의 블록이 깨끗하므로, 오래된 정보의 문제는 각각의 깨끗한 블록 제거를 디렉토리에 통지하는 것에 의해 고쳐질 수 없다. 즉, 많은 수의 통지는 트래픽의 큰 증가를 야기할 수 있다. 따라서, 각각의 깨끗한 블록 제거를 디렉토리에 통지하는 것과 오래된 디렉토리 정보를 가지는 것 사이에 상당한 트레이드오프(trade-off)가 있을 수 있으며, 이는 근본적으로 조화시키기 어려울 수 있다.

본 개시는 일반적으로, 그 중에서도 특히, 상당히 감소된 통지의 트래픽 비용으로 깨끗한 블록 제거를 디렉토리에 통지하기 위한 기술에 관한 것이다. 설명된 기술은 시스템, 방법, 장치 및 컴퓨터 판독 가능 매체를 포함하나 이에 한정되지 않는 다양한 방식으로 구현될 수 있다.

간단히 말해, 여기에 설명되는 기술은 일반적으로 캐시 제거 통지의 디렉토리로의 수집에 관련된다. 일부 예시적인 기술은 적어도 하나의 캐시 메모리의 복수의 블록 주소로부터 복수의 블록의 제거를 반영하도록 수집 테이블을 갱신하는데에 이용될 수 있다. 수집 메시지가 생성될 수 있으며, 여기서 메시지는 수집 테이블에 반영된 복수의 블록의 제거를 특정한다. 수집 메시지는 디렉토리로 전송될 수 있다. 디렉토리는 수집 메시지를 파스할 수 있고 수집 메시지에 특정된 캐시 메모리로부터의 제거를 반영하도록 복수의 디렉토리 엔트리를 갱신할 수 있다.

별도의 메시지를 통해 캐시 메모리 내 각각의 깨끗한 블록 제거를 디렉토리 컨트롤러에 통지하는 것보다는, 여기에서 설명되는 다양한 기술은 다수의 깨끗한 블록 제거를 단일 메시지로 수집하는 수집 미세지를 생성하도록 구성될 수 있다. 특히, 캐시 메모리는 메시지 수집 유닛에 결합될 수 있다. 메시지 수집 유닛은 제어 논리 및 수집 테이블을 포함할 수 있다. 수집 테이블은 깨끗한 블록 제거를 추적(track)하도록 구성될 수 있다. 제어 논리는 비트맵 포맷 또는 포인터 포맷과 같은 임의의 적절한 포맷으로 수집 메시지를 생성하도록 구성될 수 있다. 제어 논리는 또한 수집 메시지를 디렉토리 컨트롤러로 송신하도록 구성될 수 있다. 디렉토리 컨트롤러는 수집 메시지를 파스하고 수집 메시지로부터 파스된 깨끗한 블록 제거를 반영하도록 디렉토리를 갱신하도록 구성될 수 있다. 디렉토리에 캐시 제거 통지를 수집하기 위한 다양한 기술의 이러한 및 다른 태양들이 여기에서 더 상세히 설명될 것이다.

도 1은 여기에 제시되는 적어도 일부 실시예에 따라 배열되는, 예시적인 멀티코어 칩(102)의 양태를 도시하는 기능 블록도이다. 멀티코어 칩(102)은 복수의 프로세서 코어(104A-104C)(이하에서 때로는 "프로세서 코어(104)"로 집합적 또는 포괄적으로 지칭됨)를 포함할 수 있다. 멀티코어 칩(102)은 복수의 캐시 메모리(106A-106C)(이하에서 때로는 "캐시 메모리(106)"로 집합적 또는 포괄적으로 지칭됨)도 포함할 수 있다. 캐시 메모리(106) 각각은 프로세서 코어(104) 중 하나 이상관 연관될 수 있다.

도 1에 도시된 바와 같이, 캐시 메모리(106)의 제1 캐시 메모리(106A)는 프로세서 코어(104)의 제1 프로세서 코어(104A)와 연관될 수 있고, 캐시 메모리(106)의 제2 캐시 메모리(106B)는 프로세서 코어(104)의 제2 프로세서 코어(104B)와 연관될 수 있으며, 캐시 메모리(106)의 제3 캐시 메모리(106C)는 프로세서 코어(104)의 제3 프로세서 코어(104C)와 연관될 수 있다. 그러나, 일부 실시예에서 캐시 메모리(106)의 하나 이상은 프로세서 코어(104)의 둘 이상과 연관될 수 있으며, 다른 실시예에서 하나 이상의 프로세서 코어(104)가 둘 이상의 캐시 메모리(106)와 연관될 수 있다. 예를 들어, 제1 캐시 메모리(106A)가 제1 프로세서 코어(104A) 및 제2 프로세서 코어(104B) 둘 다와 연관될 수 있다. 멀티코어 칩(102)의 프로세서 코어(104)와 캐시 메모리(106) 사이의 다른 구성도 고려된다.

프로세서 코어(104) 및 캐시 메모리(106)는 하나 이상의 멀티코어 칩 노드와 논리적 또는 물리적으로 연관될 수 있다. 도 1에 도시된 바와 같이, 제1 프로세서 코어(104A) 및 제1 캐시 메모리(106A)는 제1 멀티코어 칩 노드(107A)에 포함될 수 있고, 제2 프로세서 코어(104B) 및 제2 캐시 메모리(106B)는 제2 멀티코어 칩 노드(107B)에 포함될 수 있으며, 제3 프로세서 코어(104C) 및 제3 캐시 메모리(106C)는 제3 멀티코어 칩 노드(107C)에 포함될 수 있다. 캐시 메모리(106A-106C)는 이하에서 때로는 집합적 또는 포괄적으로 "캐시 메모리(106)"로 지칭될 수 있다. 멀티코어 칩 노드(107A-107C)는 이하에서 때로는 집합적 또는 포괄적으로 "멀티코어 칩 노드(107)"로 지칭될 수 있다.

캐시 메모리(106) 각각은 하나 이상의 캐시 엔트리를 저장하도록 구성될 수 있다. 캐시 메모리(106) 내 각각의 캐시 엔트리는 데이터 구조에 따라 조직될 수 있다. 데이터 구조는 태그 필드, 상태 필드 및 데이터 필드를 포함할 수 있다. 태그 필드는 특정 엔트리가 어떠한 메모리 블록에 대응하는지를 식별하는 태그 항목을 포함할 수 있다. 상태 필드는 해당하는 태그 필드에서 식별되는 메모리 블록의 일관성 상태를 식별하는 일관성 상태 항목을 포함할 수 있다. 데이터 필드는 해당하는 태그 필드에서 식별되는 태그 값과 연관되는 데이터를 포함할 수 있다.

도 1에 도시된 바와 같이, 제1 캐시 메모리(106A)는 제1 태그 필드(108A), 제1 상태 필드(110A) 및 제1 데이터 필드(112A)에 값을 저장하도록 구성되고, 제2 캐시 메모리(106B)는 제2 태그 필드(108B), 제2 상태 필드(110B) 및 제2 데이터 필드(112B)에 값을 저장하도록 구성되며, 제3 캐시 메모리(106C)는 제3 태그 필드(108C), 제3 상태 필드(110C) 및 제3 데이터 필드(112C)에 값을 저장하도록 구성된다. 캐시 메모리(106) 각각은 임의의 수의 태그 필드, 상태 필드 또는 데이터 필드를 포함할 수 있음이 이해되어야 한다.

멀티코어 칩(102)은 또한 프로세서 코어(104)와 캐시 메모리(106)가 디렉토리 컨트롤러(118)와 통신할 수 있는 경로로서 기능하는 상호 연결 네트워크(114) 또는 버스를 포함할 수 있다. 디렉토리 컨트롤러(118)는 캐시 일관성 디렉토리(120)(이하에서 "디렉토리(120)"로 지칭됨)를 액세스하도록 적응될 수 있다. 디렉토리(120)는 단일 디렉토리로서 구현되거나 멀티코어 칩(102) 내에서 다수의 디렉토리에 걸쳐 분산될 수 있다. 일부 실시예에서, 디렉토리(120)는 디렉토리 컨트롤러(118)에 동작적으로 결합되는 멀티코어 칩(102) 상의 메모리 컴포넌트에 제공될 수 있다. 일부 실시예에서, 디렉토리(120)는 디렉토리 컨트롤러(118)의 일부인 저장 위치에 구현될 수 있다. 일부 실시예에서, 디렉토리 컨트롤러(118)는 메모리 컨트롤러일 수 있다. 일부 다른 실시예에서, 디렉토리 컨트롤러(118)는 메모리(116)와 디렉토리(120)를 제어하도록 적응되는 메모리 컨트롤러의 일부일 수 있다. 어떠한 경우에서든 디렉토리(120)는 캐시 메모리(106) 내에 저장된 블록의 일관성 상태를 추적하는데에 책임이 있을 수 있다. 도시된 메모리(116)는 오프칩(off-chip)으로 의도되며, 이는 메모리가 멀티코어 칩(102) 상에 상주(resident)하지 않고 대신 예컨대 디렉토리 컨트롤러(118)를 통해 멀티코어 칩(102)과 통신하게 배열됨을 의미한다. 일부 실시예에서, 메모리(116)는 온칩(on-chip)이며, 이는 메모리가 멀티코어 칩(102) 상에 상주함을 의미한다.

디렉토리 컨트롤러(118)는 메모리(116) 및 캐시 메모리(106)의 하나 이상의 캐시 메모리 내에 저장된 데이터의 일관성을 유지하기 위해 캐시 일관성 알고리즘을 이용할 수 있다. 설명의 편의를 위해, 그러나 한정하지 않으면서, 블록의 상태를 식별하기 위하여 배타적(exclusive) 상태, 변경된 상태, 무효의 상태, 캐싱되지 않은(uncached) 상태 또는 공유된 상태를 이용하는 캐시 일관성 알고리즘이 여기에서 이용된다. 그러나, 디렉토리(120)의 특정 구현에 따라 더 많거나 적은 상태가 있을 수 있음이 이해되어야 한다.

배타적 상태(E)는 블록이 해당하는 캐시 메모리에 배타적으로 저장됨을 나타낼 수 있다. 블록 내 데이터는 또한 메모리(116)에 저장된 데이터와 일관될 수 있다(예컨대, 데이터 블록이 깨끗함). 변경된 상태(M)는 블록이 유효하며 블록이 해당하는 캐시 메모리에 저장됨을 나타낼 수 있다. 블록 내 데이터는 메모리(116)에 저장된 데이터에 대해 변경될 수 있다(예컨대, 데이터 블록이 오염됨). 즉, 블록 내 변경된 데이터가 메모리(116)로 다시 기록되지 않았을 수 있다. 무효의 상태(I)는 블록이 무효의 엔트리를 포함함을 나타낼 수 있다. 즉, 블록이 해당하는 캐시 메모리에 저장되지 않을 수 있고, 블록에 포함된 임의의 데이터가 쓸모없는 것으로 간주될 수 있다. 캐싱되지 않은 상태(U)는 캐시 메모리(106)의 어느 것도 블록의 사본을 가지고 있지 않음을 나타낼 수 있다. 공유된 상태(S)는 블록이 깨끗하고 캐시 메모리(106)의 적어도 둘에 저장됨을 나타낼 수 있다.

도 1에 도시된 바와 같이, 캐시 일관성 디렉토리(120)는 디렉토리 태그 필드(122), 디렉토리 상태 필드(124) 및 공유자(sharers) 항목 필드(126)를 포함할 수 있다. 디렉토리 태그 필드(122)는 특정 디렉토리 엔트리가 어느 블록에 속하는지를 구별하는데에 사용될 수 있는 태그 항목을 포함할 수 있다. 디렉토리 상태 필드(124)는 해당하는 태그 필드에서 식별된 블록의 일관성 상태를 식별할 수 있는 일관성 상태 항목을 포함할 수 있다. 공유자 항목 필드(126)는 블록의 사본이 저장된 캐시 메모리(106) 중 하나 이상을 식별할 수 있다.

공유자 항목 필드(126)는 공유자 항목을 포함할 수 있다. 일부 실시예에서, 공유자 항목은 복수의 비트 각각이 캐시 메모리(106)의 단일 캐시 메모리와 연관되는 전체(full) 비트 벡터(bit vector)일 수 있다. 예를 들어, "010"은, "1"(예컨대, 논리 1)은 디렉토리 태그 필드(122) 내 태그 항목에 의해 식별되는 블록이 대응하는 캐시 메모리에 유지됨을 나타내고, "0"(예컨대, 논리 0)은 블록이 대응하는 캐시 메모리에 유지되지 않음을 나타내는 세개의 캐시 메모리를 나타낼 수 있다. 일부 다른 실시예에서, 공유자 항목은 각각의 비트가 캐시 메모리(106) 중 둘 이상의 군(group)에 대응하는 소한(coarse) 비트 벡터일 수 있다. 예를 들어, "010"은 각각의 비트가 여섯개의 캐시 메모리 중 둘을 나타내는 여섯개의 캐시 메모리를 나타낼 수 있다. 일부 실시예에서, 비트 벡터는 이진 식별자(binary identification)가 블록을 저장하는 캐시 메모리(106) 각각에 대해 열거되는 포인터 포맷일 수 있다. 예를 들어, "00"은 제1 캐시 메모리를 식별할 수 있고, "01"은 제2 캐시 메모리를 식별할 수 있으며, "10"은 제3 캐시 메모리를 식별할 수 있다.

디렉토리(120) 내 디렉토리 정보는 초기에 정확할 수 있으나, 캐시 메모리(106)가 블록 제거를 디렉토리(120)에 통지하지 않는 경우 시간이 흐르면서 디렉토리 정보가 오래될 수 있다. 위에서 언급한 바와 같이, 오래된 디렉토리 정보로부터 몇몇 문제가 발생할 수 있다. 이러한 문제 중 일부가 도 1을 참조하여 더 설명될 것이다.

도 1에 도시된 예시에서, 디렉토리(120)는 블록 A가 배타적 또는 변경된 상태(EM)로 캐시 C2에 저장되고, 블록 B가 공유된 상태(S)로 캐시 C2 및 C3에 저장되고, 블록 C가 공유된 상태(S)로 캐시 C2에 저장되고, 블록 D가 공유된 상태(S)로 캐시 C3에 저장됨을 보여주는 정보로 채워져 있다. 캐시 C2는 제2 캐시 메모리(106B)를 가리킬 수 있고, 캐시 C3는 제3 캐시 메모리(106C)를 가리킬 수 있다. 시간이 흐름에 따라, 제2 캐시 메모리(106B)(예컨대, 캐시 C2)는 디렉토리(120)에 통지하지 않고 동작 129에 도시된 바와 같이 블록 B를 제거할 수 있는데, 이는 블록 B가 C2의 관점에서 깨끗하여 조용히 제거될 수 있기 때문이다. 비슷한 이유에서, 제3 캐시 메모리(106C), 캐시 C3는 동작 130에 도시된 바와 같이 블록 B를 제거할 수 있고 동작 132에 도시된 바와 같이 블록 D를 제거할 수 있다. 이점에서 디렉토리(120)는 블록 B와 블록 D에 대해 오래된 정보를 포함할 수 있다.

오래된 디렉토리 정보의 가능성을 다루기(address) 위해 증가된 전력 소비 및/또는 지연(latency)이 발생될 수 있다. 제1 프로세서 코어(104A)가 캐시 미스(cache miss)를 등록(register)하고 동작 134에 도시된 바와 같이 디렉토리(120)로부터 블록 C로 판독 액세스를 요청하면, 디렉토리(120)는 적어도 세개의 옵션 중 하나로 응답할 수 있다. 제1 옵션은 디렉토리(120)가 블록 C에 대해 저장된 정보가 오래된 것이라고 가정하고, 동작 136에 도시된 바와 같이 메모리(116)로부터 데이터를 페치(fetch)하는 것이다. 제2 옵션은 디렉토리(120)가 블록 C에 대해 저장된 정보가 유효하다고 가정하고, 블록 C가 저장되어 있다고 디렉토리(120)가 가정하는 제2 캐시 메모리(106B)(C2)로 판독 요청을 전달하는 것이다. 제3 옵션은 디렉토리(120)가 앞서 언급한 두 작용을 조합하는 것 - 판독 요청을 전달하고 동시에 메모리(116)로부터 블록 C를 페치하는 것이다.

제1 옵션(예컨대, 판독 요청에 응답하여 메모리(116)로부터 블록 C를 페치하는 것)에 대한 일부 문제점은, 데이터가 실제로 온칩에서(예컨대, 제2 캐시 메모리(106B))에서 이용가능한 경우, 도시된 메모리(116)와 같은 오프칩 메모리로부터 페치하기 위해 발생되는 추가적인 전력 소비 및 지연을 포함할 수 있다. 제2 옵션(예컨대, 블록 C에 대해 저장된 정보가 유효하다고 가정하는 것)에 대한 일부 문제점은 디렉토리 정보가 오래된 경우 발생할 수 있다. 제2 옵션은 동작 138, 140, 142, 144에 도시된다. 이러한 대안적인 전략에서, 제1 캐시 메모리(106A)(C1)는 동작 138에 도시된 바와 같이 블록 D에 대한 판독 요청을 디렉토리(120)로 전송한다. 디렉토리 정보가 최신이라는 가정 하에서 동작하면서, 디렉토리(120)는 이후 동작 140에 도시된 바와 같이 판독 요청을 제3 캐시 메모리(106C)(C3)로 전달한다. 앞서 설명한 바와 같이, 제3 캐시 메모리(106C)(C3)는 동작 132에서 블록 D를 제거하였다. 그 결과, 제3 캐시 메모리(106C)(C3)는 블록 D에 대한 어떠한 데이터도 캐시되지 않는다는 지시(indication)로 응답한다. 이점에서, 디렉토리(120)는 블록 D에 대한 정보가 오래된 것이라 결정하고 동작 144에 도시된 바와 같이 메모리(116)로부터 블록 D에 대한 데이터를 페치한다. 이제 디렉토리(120)가 블록 D에 대한 최신의 정보를 포함하나, 오래된 정보를 검출하고 데이터를 페치하기 위해 추가적인 전력 소비 및 지연이 발생될 수 있다. 제3 옵션(예컨대, 동시에 메모리(116)로부터 페치하고 요청을 전달하는 것)에 대한 일부 문제점은 지연을 감소시킬 수 있는데, 이는 디렉토리 정보가 오래되지 않은 경우 온칩에서 이용가능한 데이터가 회수(retrieve)될 수 있기 때문이다. 그러나, 이러한 감소된 지연은 제1 옵션 및 제2 옵션을 동시해 수행하기 위해 전력 소비를 상당히 증가시키는 것의 희생으로 올 수 있다. 즉, 이러한 제3 옵션은 에너지 효율적으로 간주될 수 없다.

대응하는 메모리 블록이 더 이상 캐시되지 않기 때문에 더 이상 필요로 되지 않는 일부 디렉토리 엔트리가 디렉토리(120) 내 공간을 차지하므로, 디렉토리(120)는 불필요하게 큰 저장 오버헤드를 차지할 수 있다. 예를 들어, 일부 멀티코어 칩에서 사용되는 (예컨대, 일부 필드가 생략된) 축약된 디렉토리 포맷도 멀티코어 칩의 이용가능한 캐시 메모리의 삼분의 일 이상을 차지할 수 있다. 캐시되지 않은 블록을 포함하는 엔트리가 제거될 수 있으므로, 최신의 디렉토리 정보로, 디렉토리(120)는 동일한 성능을 달성하기 위해 더 적은 수의 엔트리가 공급될 수 있다.

디렉토리 엔트리에 대한 교체 정책(replacement policy)은 오래된 정보에 대한 의존 때문에 준최적으로(suboptimally) 수행할 수 있다. 동작 146에 도시된 바와 같이 디렉토리(120)가 가득 차 있고, 블록 E를 판독하기 위한 요청이 제2 캐시 메모리(106B)(C2)로부터 수신된다고 가정한다. 디렉토리(120)가 블록 E에 대한 정보를 포함하고 있지 않으므로, 디렉토리(120)는 기존의 엔트리를 제거하고 새로운 엔트리를 삽입한다. 디렉토리(120)가 오버플로(overflow)를 허용하지 않으면, 디렉토리(120)의 공유자 항목 필드(126) 내의 공유자 목록에 표시된 모든 캐시로부터 블록이 무효화될 수 있다. 오버플로는 여기에서 디렉토리(120)에 맞지 않고 메모리(116)에 저장된 엔트리 또는 엔트리들로서 정의될 수 있다. 메모리(116)에 저장된 엔트리 또는 엔트리들은 추후 필요로 되는 경우 요구에 따라(on-demand) 페치될 수 있다. 따라서, 일부 엔트리는 디렉토리(120)에 저장될 수 있는 한편, 다른 엔트리(예컨대, 오버플로 엔트리)는 메모리(116)에 저장된다. 그 결과, 효과적인 제거 정책은 가장 적은 수의 공유자를 포함하는 희생자(victim) 엔트리를 선택할 수 있어, 가능한 적은 캐시가 무효화될 수 있다. 불행히도 오래된 정보 때문에, 가장 적은 공유자는 여전히 캐시되고 있는 블록과 연관되는 것으로 밝혀질 수 있다.

예시로서, 도 1은 가장 적은 공유자를 가지는 하나의 블록이 블록 C라고 도시하고 있으며, 이는 동작 148에서 제거를 위해 선택될 수 있다. 블록 C를 제거하는 것은 동작 150에 도시된 바와 같이 제2 캐시 메모리(106B)로부터 블록 C의 무효화를 야기한다. 예를 들어, 디렉토리 컨트롤러(118)는 블록 C에 관한 무효화 메시지를 제2 캐시 메모리(106B)로 송신하도록 구성될 수 있다. 제2 캐시 메모리(106B)(C2)와 연관되는 제2 프로세서 코어(104B)에 의해 블록 C가 여전히 필요로 될 수 있으므로, 블록 C(C2)의 무효화는 성능 저하를 야기할 수 있다. 제2 프로세서 코어(104B)가 블록 C를 필요로 하는 경우, 제2 프로세서 코어(104B)는 블록 C에 대한 액세스기 시도될 때 캐시 미스를 경험할 것이다. 반면에, 블록 B는 제2 캐시 메모리(106B)(C2) 및 제3 캐시 메모리(106C)(C3)에 의해 공유되는 것으로 디렉토리(120)에 열거되나, 사실상 블록 B는 이러한 캐시 메모리 중 어느 것에 의해서도 더 이상 캐시되지 않는다. 블록 B가 제거를 위해 선택된 경우, 블록 B는 캐시 메모리(106) 중 어느 것에서도 더 이상 캐시되지 않기 때문에 어떠한 성능 불이익도 없을 것이다.

오래된 디렉토리 정보의 네번째 문제는 과도한 무효화 트래픽일 수 있다. 앞서 설명한 바와 같이, 기록 요청의 결과 디렉토리(120)로부터 블록이 제거되는 경우, 디렉토리 컨트롤러(118)는 블록의 사본을 유지하면서 디렉토리(120)에 의해 기록된 각각의 캐시 메모리로 블록에 관한 무효화 메시지를 송신하도록 구성될 수 있다. 이러한 캐시 메모리로 전송되는 그러한 무효화 메시지는, 캐시 메모리의 전체 또는 일부가 더 이상 블록의 사본을 포함하지 않는 최신의 정보를 디렉토리(120)가 가지는 경우 회피될 수 있다.

여기에 개시된 기술은 메시지 수집 유닛(MAU)(128)을 이용하여 전술된 다양한 문제를 적어도 부분적으로 다룰 수 있다. MAU(128)는 디렉토리(120)에 제거 통지를 수집하도록 구성될 수 있다. MAU(128)는 도 3을 참조하여 이하에서 더 상세히 설명될 것이다.

도 1은 하나의 멀티코어 칩(102), 하나의 상호 연결 네트워크(114), 하나의 메모리(116), 하나의 디렉토리 컨트롤러(118) 및 하나의 캐시 일관성 디렉토리(120)를 도시하고 있다. 그러나, 동작 환경(100)의 일부 구현은 둘 이상의 멀티코어 칩(102), 둘 이상의 상호 연결 네트워크(114), 둘 이상의 메모리(116), 둘 이상의 디렉토리 컨트롤러(118) 및 둘 이상의 캐시 일관성 디렉토리(120)를 포함할 수 있음이 이해되어야 한다. 따라서, 여기에 설명되는 다양한 실시예는 동작 환경(100)의 일부 예시를 예시하는 것으로 이해되어야 하고, 어떠한 방식으로든 제한하는 것으로서 해석되어서는 안된다.

도 2는 여기에 제시되는 적어도 일부 실시예에 따라 배열되는, 비트맵 포맷의 수집된 제거 통지 메시지 및 포인터 포맷의 수집된 제거 통지 메시지에 대한 전통적인 디렉토리 프로토콜에서의 블록당 제거 통지 메시지의 사이즈 사이의 예시적인 비교를 도시하는 표(200)이다. 여기에서 더 상세히 설명될 바와 같이, 제거 메시지는 단일 메시지가 다수의 블록 정보를 캡슐화(encapsulate)할 수 있도록 제거 메시지 포맷을 변경함으로써 수집될 수 있다.

표(200)는 제거 통지 메시지가 수집되는지 여부에 따라 어떻게 제거되는 다섯개의 제거된 블록이 다른 양의 트래픽을 소비할 수 있는지와 어떻게 제거 통지 메시지가 수집될 수 있는지를 보여준다. 표(200)는 제거된 블록 주소 부분(202) 및 제거 메시지의 사이즈 부분(204)을 포함한다. 예시된 제거된 블록 주소 부분(202)은 다섯개의 제거된 블록에 대한 블록 주소로 채워져 있다. 제거 메시지의 사이즈 부분(204)은 전통적인 블록당 제거 메시지 부분(206), 메시지 수집 비트맵 포맷 부분(208) 및 메시지 수집 포인터 포맷 부분(210)을 포함한다.

도 2에 도시된 바와 같이, 이러한 부분들에 보여지는 메시지 사이즈는 메시지의 주소 부분을 포함한다. 그러나, 일부 다른 실시예에 따르면, 패킷 헤더, 명령 유형(command type) 또는 에러 검출/정정 코드와 같은 다른 정보를 인코딩하도록 추가적인 비트 또는 바이트가 각각의 메시지에 부가될 수 있다. 도 2에 도시된 바와 같이, 메시지 사이즈는 64 바이트 블록 사이즈를 가지는 42 비트 물리적 주소를 가정한다. 그러나, 다른 물리적 주소에 대한 사이즈 및 블록 사이즈가 사용될 수 있음이 이해되어야 한다.

도 2에 도시된 바와 같이, 각각의 전통적인 블록당 제거 메시지 부분은 아홉개의 십육진수(hexadecimal digit)의 시퀀스(sequence)로 인코딩될 수 있다. 각각의 십육진수는 4 비트를 나타낼 수 있다. 그 결과, 각각의 전통적인 블록당 제거 메시지 부분은 36 비트(9 십육진수 x 십육진수당 4 비트)에 달할 수 있고, 그 결과 블록당 4.5 바이트(36 비트 / 비트당 8 바이트) 사이즈가 될 수 있다. 각각의 블록 제거가 디렉토리(120)에 메시지를 전송하는 경우, 전통적인 블록당 제거 기법에 대한 표(200)의 총계 부분(212)에 도시된 바와 같이, 22.5 바이트(5 메시지 x 메시지당 4.5 바이트)의 총 트래픽으로 다섯개의 메시지가 전송된다.

도 2에 도시된 바와 같이, 다섯개의 전통적인 블록당 제거 메시지 부분은 비트맵 포맷 또는 포인터 포맷 중 하나로 단일의 수집 메시지로 수집될 수 있다. 특히, 다섯개의 전통적인 블록당 제거 메시지 부분이 루트(root)(214)(예컨대, 4C5FA7A0)와 같은 공통의 루트를 포함한다는 관찰(observation)이 이루어질 수 있다. 즉, 마지막 십육진수가 다섯개의 전통적인 블록당 제거 메시지 부분 사이에 다르다. 따라서, 다섯개의 블록당 제거 메시지 부분은 루트(214) 및 마지막 십육진수의 식별자를 포함하는 단일의 수집 메시지 부분으로 수집될 수 있다. 마지막 십육진수는 비트맵 포맷 또는 포인터 포맷으로 인코딩될 수 있다.

비트맵 포맷에서 수집 메시지 부분은 여덟개의 십육진수(예컨대, 루트(214))와 비트맵(216)의 시퀀스로서 인코딩될 수 있다. 비트맵 포맷에 대한 총계 부분(212)에 도시된 바와 같이, 루트(214)는 사이즈 1 킬로바이트의 영역과 열여섯개의 가능한 블록을 나타낼 수 있다. 비트맵(216)은 영역 내의 어떠한 블록이 캐시로부터 제거되었는지 나타내는데에 이용될 수 있으며, 여기서 "1"로 설정된 적절한 비트가 제거된 블록을 나타내고 "0"이 제거되지 않은 블록을 나타낸다. 도 2에 도시된 바와 같이 16 비트 비트맵이 이용되나, 특정 구현에 따라 다른 비트맵 사이즈가 사용될 수 있다.

주어진 비트 스트링(bit string)에서의 "1"의 개수는 여기에서 군집 개수(population count 또는 "popcount")로 지칭된다. 예를 들어, 비트맵(216)은 다섯개의 "1" 비트를 포함하며, 따라서 비트맵(216)에 대한 군집 개수는 5이다. 다른 예시로서, 비트 스트링 "0111"은 세개의 "1" 비트를 포함하며, 따라서 비트 스트링 "0111"에 대한 군집 개수는 3이다.

각각의 십육진수는 비트맵 포맷에서 4 비트의 수집 메시지를 나타낼 수 있다. 그 결과, 예시적인 비트맵 포맷의 수집 메시지 부분은 48 비트(8 십육진수 x 십육진수당 4 비트 + 16 비트) 또는 6 바이트(48 비트 / 비트당 8 바이트)일 수 있다. 즉, 비트맵 포맷의 수집 메시지 부분은 비트맵 포맷에 대한 총계 부분(220)에 도시된 바와 같이 총 6 바이트에 대해 4 바이트 루트 및 2 바이트 비트맵을 포함할 수 있다.

포인터 포맷의 수집 메시지 부분은 여덟개의 십육진수(예컨대, 루트(214)) 및 루트(214)를 공유하는 블록 주소의 십육진 값의 목록(218)의 시퀀스로서 인코딩될 수 있다. 루트(214)는 비트맵 포맷에 대한 총계 부분(212)에 도시된 바와 같이, 1 킬로바이트 사이즈의 영역과 열여섯개의 가능한 블록을 나타낼 수 있다. 영역 내 어떠한 블록이 캐시로부터 제거되었는지 나타내기 위해, 목록(218)이 이용될 수 있고, 여기에서 목록(218)에 포함된 각각의 십육진 값은 제거된 블록 또는 제거되지 않은 블록을 나타낸다.

각각의 십육진수는 포인터 포맷의 4 비트의 수집 메시지를 나타낼 수 있다. 그 결과, 예시적인 포인터 포맷의 수집 메시지는 52 비트(8 십육진수 x 십육진수당 4 비트 + 5 십육진수 x 십육진수당 4 비트) 또는 6 바이트(52 비트 / 비트당 8 바이트)일 수 있다. 즉, 포인터 포맷의 수집 메시지 부분은 포인터 포맷에 대한 총계 부분(222)에 도시된 바와 같이 총 6.5 바이트에 대해 4 바이트 루트와 2.5 바이트 목록을 포함할 수 있다.

도 2에 도시된 바와 같이, 총 메시지 사이즈가 상당히 감소되도록 다섯개의 메시지가 하나의 제거 통지 메시지로 수집될 수 있다. 특히, 표(200)의 총계 부분(220 및 222) 내 각각의 트래픽 총계에 의해 도시되는 바와 같이, 수집된 통지 매시지에 대해 비트맵 포맷을 사용하는 것은 총 트래픽을 22.5 바이트에서 6 바이트로 감소시킬 수 있고, 포인터 포맷을 사용하는 것은 총 트래픽을 22.5 바이트에서 6.5 바이트로 감소시킬 수 있다. 이러한 예시에서, 메시지 수집은 비트맵 포맷을 이용하여 메시지 사이즈, 트래픽 또는 트래픽 관련 에너지 사용을 약 73%(1 - 6 바이트 / 22.5 바이트) 감소시킬 수 있고, 포인터 포맷을 이용하여 약 71%(1 - 6.5 바이트 / 22.5 바이트) 감소시킬 수 있다. 여기에서 트래픽 관련 에너지는 트래픽에 대해 발생된 에너지 소비로 정의될 수 있으며, 프로세서, 캐시, 논리 및/또는 다른 컴포넌트에 대해 발생된 에너지 소비를 제외한다.

도 3은 여기에서 제시되는 적어도 일부 실시예에 따라 배열되는, 메시지 수집 유닛(128)이 제거 통지를 디렉토리(120)에 수집하는데에 이용되는 멀티코어 칩(102)의 멀티코어 칩 노드(107)의 태양을 도시하는 기능 블록도이다. 멀티코어 칩 노드(107)는 하나 이상의 프로세서 코어(104) 및 캐시 메모리(106)를 포함할 수 있다. 멀티코어 칩 노드(107)는 또한 도 1을 참조하여 위에서 소개된 MAU(128)와 같은 메시지 수집 유닛을 포함할 수 있다. 일부 실시예에 따르면, MAU(128)는 특정 레벨의 캐시 메모리 내에 구현될 수 있다. 예를 들어, MAU(128)는 마지막 레벨 캐시 내에 구현될 수 있다. 도 3에 도시된 바와 같이, MAU(128)는 캐시 메모리(106)에 동작적으로 결합된 것으로 도시된다. 그러나, MAU(128)가 캐시 메모리(106)의 일부로서 구현될 수 있음이 이해되어야 한다.

MAU(128)는 수집 테이블(302)과 통신하도록 배열되는 제어 논리(300)를 포함할 수 있다. 제어 논리(300)는 캐시 메모리(106)로부터의 하나 이상의 블록의 제거를 반영하도록 수집 테이블(302)을 갱신하도록 구성될 수 있다. 제어 논리(300)는 또한 수집 테이블(302)에서 반영된 대로 블록 제거가 특정될 수 있는 수집 메시지를 생성하도록 구성될 수 있다. 제어 논리(300)는 수집 메시지를 디렉토리 컨트롤러(118)로 전송하도록 더 구성될 수 있다. 디렉토리 컨트롤러(118)는 수집 메시지를 파스하고, 수집 메시지로부터 파스된 캐시 메모리(106)로부터의 제거를 반영하도록 디렉토리(120) 내 하나 이상의 디렉토리 엔트리를 갱신하도록 구성될 수 있다.

수집 테이블(302)은 도시된 예시에서 태그 필드(304) 및 비트맵 필드(306)와 같은 다수의 필드에 따라 조직되는 데이터 구조이다. 태그 필드(304)는 각각이 캐시 메모리(106)로부터 제거된 둘 이상의 블록 주소 사이에서 공유될 수 있는 하나 이상의 공통의 루트에 대응하는 값을 포함할 수 있다. 도 3에 도시된 예시에서, 태그 필드(304)는 루트(214)에 대응하는 값을 포함한다. 비트맵 필드(306)는 하나 이상의 비트맵에 대응하는 값을 포함할 수 있다. 도 3에 도시된 예시에서, 비트맵 필드(306)는 비트맵(216)에 대한 값을 포함한다.

MAU(128)는 또한 포인터 포맷 전환 유닛(308) 및 멀티플렉서(310)를 포함할 수 있다. 포인터 포맷 전환 유닛(308)은 비트맵(216)과 같은 비트맵을 비트맵 내 복수의 비트에 대응하는 복수의 포인터 값으로 전환하도록 구성될 수 있다. 멀티플렉서(310)는 제어 논리(300)의 명령으로 수집 메시지를 디렉토리 컨트롤러(118)로 전송하도록 구성될 수 있다. 전술한 바와 같이, 디렉토리 컨트롤러(118)는 수집 메시지를 파스하고 수집 메시지로부터 파스된 캐시 메모리(106)로부터의 제거를 반영하도록 디렉토리(120) 내 하나 이상의 디렉토리 엔트리를 갱신하도록 구성될 수 있다.

캐시 메모리(106)가 오염된 블록을 제거하는 경우, 캐시 메모리(106)는 전통적인 디렉토리 프로토콜에서와 같이 디렉토리 컨트롤러(118)를 통해 디렉토리(120)에 통지할 수 있다. 그러나, 깨끗한 블록이 제거되는 경우, 전통적인 디렉토리 프로토콜에서와 같이 조용히 제거되는 것보다, 캐시 메모리(106)는 제어 논리(300)를 통해 MAU(128)에 통지할 수 있다. 이후, 제어 논리(300)는 수집 테이블(302)이 제거된 블록의 블록 주소에 대응하는 엔트리를 포함하는지 결정할 수 있다. 수집 테이블(302)이 블록 주소에 대응하는 테이블 엔트리를 포함하지 않는다고 결정하는 것에 응답하여, 제어 논리(300)는 수집 테이블(302) 내 테이블 엔트리를 생성할 수 있고 블록 주소로부터 블록의 제거를 반영하도록 엔트리를 갱신할 수 있다. 수집 테이블(302)이 블록 주소에 대응하는 테이블 엔트리를 포함한다고 결정하는 것에 응답하여, 제어 논리(300)는 블록 주소로부터 블록의 제거를 반영하도록 테이블 엔트리를 갱신할 수 있다. 예를 들어, 제어 논리(300)는 제거된 블록에 대응하는 비트의 값을 "0" 비트 값에서 "1" 비트 값으로 바꾸도록 구성될 수 있다.

엔트리가 MAU(128)로부터 제거되는 것으로 결정되는 경우, 제어 논리(300)는 제1 수집 메시지를 생성하도록 구성될 수 있다. 제1 수집 메시지는 루트(214)와 같은 태그 필드(304)로부터 추출되는 태그 부분(예컨대, 루트 부분) 및 비트맵(216)과 같은 비트맵 필드로부터 추출되는 비트맵 부분을 포함할 수 있다. 제어 논리(300)는 또한 연관된 블록이 제거되는지 제거되지 않는지를 가리키는 값을 가지는 비트맵 내 복수의 비트에 대응하는 복수의 포인터 값으로 비트맵(216)을 전환하기 위한 포인터 포맷 전환 유닛(308)의 동작을 조정(coordinate)하도록 구성될 수 있다. 제어 논리(300)는 제2 수집 메시지를 생성하도록 더 구성될 수 있다. 제2 수집 메시지는 태그 부분 및 복수의 포인터 값을 포함하는 포인터 부분을 포함할 수 있다. 제어 논리(300)는 또한 메시지 중 어느 것이 더 작은 데이터 사이즈를 가지는지에 기초하여 제1 또는 제2 수집 메시지를 선택하도록 구성될 수 있다. 제어 논리(300)는 제어 논리(300)에 의해 이루어진 제1 수집 메시지 또는 제2 수집 메시지의 선택에 기초하여 디렉토리 컨트롤러(118)를 통해 디렉토리(120)로 제1 수집 메시지 또는 제2 수집 메시지 중 하나를 전송하도록 멀티플렉서(310)의 동작을 조정(예컨대, 지시)하도록 구성될 수 있다.

도 4는 여기에 제시되는 적어도 일부 실시예에 따라 배열되는, 캐시 제거 통지를 디렉토리에 수집하도록 구성되는 예시적인 프로세스(400)를 도시하는 흐름도이다. 프로세스(400)는 하나 이상의 블록(402-410)에 의해 도시된 다양한 동작, 기능 또는 작용을 포함할 수 있다.

프로세스(400)는 블록 402(블록 주소로부터 블록의 제거를 반영하도록 수집 테이블 갱신)에서 시작할 수 있으며, 여기서 MAU(128)는 캐시 메모리(106) 중 적어도 하나와 같은 적어도 하나의 캐시 메모리의 복수의 블록 주소로부터 복수의 블록의 제거를 반영하도록 수집 테이블(302)을 갱신하도록 구성될 수 있다. 일부 실시예에 따르면, 제거된 블록은 깨끗한 블록이다. 일부 다른 실시예에 따르면, MAU(128)는 하나 이상의 오염된 블록의 제거를 무시하도록 구성될 수 있다. 블록 402에 블록 404가 뒤따를 수 있다.

블록 404(수집 테이블에 반영된 제거를 특정하는 수집 메시지 생성)에서, MAU(128)는 수집 메시지를 생성하도록 구성될 수 있다. 수집 메시지는 수집 테이블(302)에 반영된 복수의 블록의 제거를 특정할 수 있다. 일부 실시예에서, 수집 메시지는 비트맵 포맷으로 형식화될(formatted) 수 있다. 일부 다른 실시예에서, 수집 메시지는 포인터 포맷으로 형식화될 수 있다. 블록 404에 블록 406이 뒤따를 수 있다.

블록 406(디렉토리 컨트롤러로 수집 메시지 전송)에서, MAU(128)는 디렉토리 컨트롤러(118)로 수집 메시지를 전송하도록 구성될 수 있다. 블록 406에 블록 408이 뒤따를 수 있다.

블록 408(수집 메시지 수신 및 파스)에서, 디렉토리 컨트롤러(118)는 제거를 식별하도록 수집 메시지를 수신 및 파스하도록 구성될 수 있다. 블록 408에 블록 410이 뒤따를 수 있다.

블록 410(수집 메시지에 특정된 제거를 반영하도록 디렉토리 갱신)에서, 디렉토리 컨트롤러(118)는 수집 메시지에 특정된 제거를 반영하도록 디렉토리(120)를 갱신하도록 구성될 수 있다. 앞서 언급한 바와 같이, 블록 410 후에, 프로세스(400)는 (예컨대, 주기적으로, 계속적으로, 또는 요구에 따라) 반복할 수 있거나, 아무때나 종료할 수 있다.

도 5는 여기에 제시되는 적어도 일부 실시예에 따라 배열되는, 캐시 제거를 처리하도록 적응되는 예시적인 프로세스(500)를 도시하는 흐름도이다. 프로세스(500)는 하나 이상의 블록(502-514)에 의해 도시된 다양한 동작, 기능 또는 작용을 포함할 수 있다.

프로세스(500)는 블록 502(블록 제거)에서 시작할 수 있으며, 여기서 캐시 메모리(106)가 블록을 제거하도록 구성될 수 있다. 블록 502에 블록 504가 뒤따를 수 있다.

블록 504(오염된 블록)에서, 블록 502에서 캐시 메모리(106)에 의해 제거된 블록이 오염된 블록인 경우, 프로세스(500)는 블록 504로부터 블록 506으로 진행할 수 있다. 블록 504(오염된 블록?)에서, 블록 502에서 캐시 메모리(106)에 의해 제거된 블록이 오염된 블록이 아닌 경우, 프로세스(500)는 블록 504에서 블록 508로 진행할 수 있다. 위에서 설명한 바와 같이, 오염된 블록은 메모리(116)과 같은 메모리에 저장된 데이터에 대해 변경된 데이터를 포함하는 블록이다.

블록 506(디렉토리 컨트롤러에 오염된 블록 제거 통지)에서, 디렉토리 컨트롤러(118)가 디렉토리(120)에 오염된 블록 제거를 통지할 수 있도록, 캐시 메모리(106)는 디렉토리 컨트롤러(118)에 통지 메시지를 전송하도록 구성될 수 있다. 통지 메시지는 새로운 데이터 블록 값을 포함할 수 있다. 앞서 언급한 바와 같이, 블록 506 후에, 프로세스(500)는 (예컨대, 주기적으로, 계속적으로, 또는 요구에 따라) 반복할 수 있거나, 아무때나 종료할 수 있다.

블록 508(제어 논리를 통해 메시지 수집 유닛에 깨끗한 블록 제거 통지)에서, 제어 논리(300)가 MAU(128)에 깨끗한 블록 제거를 통지할 수 있도록, 캐시 메모리(106)는 제어 논리(300)에 통지 메시지를 전송하도록 구성될 수 있다. 예를 들어, 캐시 메모리(106)에 의해 블록이 제거되는 경우, 블록이 깨끗하면 블록 주소의 태그 부분이 제어 논리(300)로 전송될 수 있다. 블록 508에 블록 510이 뒤따를 수 있다.

블록 510(수집 테이블이 블록의 블록 주소에 대응하는 엔트리 포함?)에서, 제어 논리(300)로부터 수신된 메시지에 응답하여, MAU(128)는 수집 테이블(302)이 제거된 블록의 블록 주소에 대응하는 엔트리를 포함하는지 결정하도록 구성될 수 있다. MAU(128)가 수집 테이블(302)이 제거된 블록의 블록 주소에 대응하는 엔트리를 포함하지 않는다고 결정하는 경우, 프로세스(500)는 블록 510에서 블록 512로 진행할 수 있다. MAU(128)가 수집 테이블(302)이 제거된 블록의 블록 주소에 대응하는 엔트리를 포함한다고 결정하는 경우, 프로세스(500)는 블록 510에서 블록 514로 진행할 수 있다.

블록 512(수집 테이블 내 엔트리 생성)에서, 제어 논리(300)로부터 수신된 메시지에 응답하여, MAU(128)는 수집 테이블(302)에 제거된 블록의 블록 주소에 대응하는 엔트리를 생성하도록 구성될 수 있다. 블록 512에 블록 514가 뒤따를 수 있다.

블록 514(블록 주소로부터 블록의 제거를 반영하도록 수집 테이블 엔트리 갱신)에서, 제어 논리(300)로부터 수신된 메시지에 응답하여, MAU(128)는 블록 주소로부터 블록의 제거를 반영하도록 블록 512에서 생성된 엔트리를 갱신하도록 구성될 수 있다. 앞서 언급된 바와 같이, 블록 514 후에, 프로세스(500)는 (예컨대, 주기적으로, 계속적으로, 또는 요구에 따라) 반복할 수 있거나, 아무때나 종료할 수 있다.

도 6은 여기에서 제시되는 적어도 일부 실시예에 따라 배열되는, 수집 제거 통지 메시지를 생성하도록 적응되는 예시적인 프로세스(600)를 도시하는 흐름도이다. 프로세스(600)는 하나 이상의 블록(602-608)에 의해 도시된 다양한 동작, 기능 또는 작용을 포함할 수 있다.

프로세스(600)는 블록 602(수집 테이블로부터 엔트리와 연관된 태그 부분 및 비트맵 부분 회수)에서 시작할 수 있으며, 여기에서 MAU(128)는 엔트리가 수집 테이블(302)로부터 제거되어야 한다고 결정하도록 구성될 수 있다. 블록 602에서, MAU(128)는 또한 엔트리가 수집 테이블(302)로부터 제거되어야 한다는 결정에 응답하여 수집 테이블(302)로부터 태그 부분(예컨대, 루트) 및 비트맵 부분을 회수하도록 구성될 수 있다. 블록 602에 블록 604가 뒤따를 수 있다.

블록 604(태그 부분 및 비트맵 부분을 포함하는 제1 수집 메시지 생성)에서, 수집 테이블(302)로부터 태그 부분 및 비트맵 부분을 회수하는 것에 응답하여, MAU(128)는 태그 부분과 비트맵 부분을 포함할 수 있는 제1 수집 메시지를 생성하도록 구성될 수 있다. 블록 604에 블록 606이 뒤따를 수 있다.

블록 606(비트맵 부분을 비트맵 내 복수의 비트에 대응하는 복수의 포인터 값으로 전환)에서, 제1 수집 메시지를 생성하는 것에 응답하여, MAU(128)는 비트맵 부분을 비트맵 내 복수의 비트에 대응하는 복수의 포인터 값으로 전환하도록 포인터 포맷 전환 유닛(312)을 지시하도록 구성될 수 있다. 블록 606에 블록 608이 뒤따를 수 있다.

블록 608(태그 부분 및 복수의 포인터 값을 포함하는 제2 수집 메시지 생성)에서, 제1 메시지를 생성하는 것에 응답하여, MAU(128)는 태그 부분 및 복수의 포인터 값을 포함할 수 있는 제2 수집 메시지를 생성하도록 구성될 수 있다. 블록 608 후에, 프로세스(600)는 (예컨대, 주기적으로, 계속적으로, 또는 요구에 따라) 반복할 수 있거나, 종료할 수 있다.

도 7은 여기에 제시되는 적어도 일부 실시예에 따라 배열되는, 수집 제거 통지 메시지를 선택하도록 적응되는 예시적인 프로세스를 도시하는 흐름도이다. 프로세스(700)는 하나 이상의 블록(702-708)에 의해 도시된 다양한 동작, 기능 또는 작용을 포함할 수 있다. 또한, 프로세스(700)는 도 6을 참조하여 위에서 설명된 프로세스(600)에 따라서와 같이, 제1 수집 메시지 및 제2 수집 메시지가 각각 비트맵 포맷 및 포인터 포맷으로 생성되었음을 가정할 수 있다.

프로세스(700)는 블록 702(제1 수집 메시지의 제1 데이터 사이즈 및 제2 수집 메시지의 제2 데이터 사이즈 결정)에서 시작할 수 있으며, 여기서 MAU(128)는 제1 수집 메시지의 제1 데이터 사이즈 및 제2 수집 메시지의 제2 데이터 사이즈를 결정하도록 구성될 수 있다. MAU(128)는 도 6에 도시된 프로세스(600)를 참조하여 위에서 설명된 것과 같은 제1 수집 메시지 및 제2 수집 메시지의 생성에 응답하여 제1 수집 메시지의 제1 데이터 사이즈 및 제2 수집 메시지의 제2 데이터 사이즈를 결정할 수 있다. 블록 702에 블록 704가 뒤따를 수 있다.

블록 704(제1 데이터 사이즈 < 제2 데이터 사이즈?)에서, 제1 수집 메시지의 제1 데이터 사이즈 및 제2 수집 메시지의 제2 데이터 사이즈를 결정하는 것에 응답하여, MAU(128)는 데이터 사이즈를 평가(evaluate)하고 제1 데이터 사이즈가 제2 데이터 사이즈보다 작은지 여부를 결정하도록 구성될 수 있다. MAU(128)가 제1 데이터 사이즈가 제2 데이터 사이즈보다 작다고 결정하는 경우, 프로세스(700)는 블록 704에서 블록 706으로 진행할 수 있다. MAU(128)가 제1 데이터 사이즈가 제2 데이터 사이즈보다 작지 않다고 결정하는 경우, 프로세스(700)는 블록 704에서 블록 708로 진행할 수 있다.

블록 706(캐시 일관성 디렉토리로 제1 수집 메시지 전송)에서, MAU(128)는 디렉토리(120)로 제1 수집 메시지를 전송하도록 구성될 수 있다. 블록 706 후에, 프로세스(700)는 (예컨대, 주기적으로, 계속적으로, 또는 요구에 따라) 반복할 수 있거나, 종료할 수 있다.

블록 708(캐시 일관성 디렉토리로 제2 수집 메시지 전송)에서, MAU(128)는 디렉토리(120)로 제2 수집 메시지를 전송하도록 구성될 수 있다. 블록 708 후에, 프로세스(700)는 (예컨대, 주기적으로, 계속적으로, 또는 요구에 따라) 반복할 수 있거나, 종료할 수 있다.

앞의 설명은 적어도 부분적으로 어떻게 깨끗한 블록 제거 통지가 단일 메시지로 수집될 수 있는지, 얼마나 많이 통지 메시지 사이즈가 수집을 통해 감소될 수 있는지, 수집 메시지에 대한 두개의 예시적인 포맷 및 포맷 중 하나를 어떻게 선택하는지, 및 전통적인 디렉토리 기반 일관성 멀티코어 시스템에 제거 메시지 수집을 통합하도록 구성되는 시스템 컴포넌트에 관한 것이다. 이하의 상세한 설명은 메시지 수집 유닛 및 특정 구현에서 무엇이 최적의 유닛 사이즈로 고려되는지를 예시한다. 이하의 설명은 수학적 모델의 구성, 모델의 분석 및 모델의 관찰에 기초한 해결책의 설계로 시작한다.

먼저, x개의 블록의 MAU 입도를 가정한다. MAU 입도는 비트맵 필드(306)에 저장된 비트맵에 포함된 비트의 수에 의해 나타내어질 수 있다. 예를 들어, 도시된 비트맵(216)이 16 비트를 포함하므로, 비트맵(216)의 MAU 입도는 16 블록일 수 있다. 비트맵(216)은 그 중 다섯개가 "1" 비트인 열여섯개의 비트를 포함한다. 위에서 설명한 바와 같이, 주어진 비트 스트링에서 "1" 비트의 수는 여기에서 군집 개수로 지칭된다. 비트맵(216)이 그 중 다섯개가 "1" 비트인 열여섯개의 비트를 포함할 수 있으므로, 비트맵(216)은 5의 군집 개수를 가질 수 있다. 또한 위에서 설명한 바와 같이, 군집 개수는 제거된 블록의 수를 나타낼 수 있다. 즉, 비트맵(216)이 다섯개의 "1" 비트를 포함하기 때문에 비트맵(216)에 대한 군집 개수는 5일 수 있으며, 이는 다섯개의 제거된 블록이 있음을 가리킨다.

x개의 블록의 입도의 비트맵의 군집 개수의 평균 값(즉, 제거된 블록의 평균 개수)를 표현하기 위한 함수가 사용될 수 있다. 평균은 다양한 블록의 군집 개수를 합하고 합을 세어진 블록의 수로 나눔으로써 계산될 수 있다. 평균은 고정된 주기의 시간에 걸쳐 계산될 수 있으며, 이는 매 특정 시간 간격마다 다시 계산될 수 있다. x개의 블록의 입도의 비트맵의 군집 개수의 평균 값을 표현하기 위한 함수는 여기에서 pop(x)로 지칭될 수 있다. 설명의 편의를 위해, 함수 pop(x)는 "군집 개수 함수(popcount function)"로 지칭될 수 있다.

비트맵 포맷으로, 수집 메시지 사이즈는 c + x/8 바이트로 결정될 수 있으며, 여기서 c는 루트의 사이즈(예컨대, 4 바이트)와 패킷 헤더 및 에러 정정/검출 코드를 위해 사용되는 추가적인 비트를 나타내는 상수이고, x/8은 바이트당 8 비트에 의해 나누어진 x 블록 수를 나타낸다. 예를 들어, 도 2에 도시된 비트맵 포맷에서 수집 메시지 부분의 사이즈는 비트맵 포맷에 대한 총계 부분(220)에 도시된 바와 같이 4 바이트 + 16/8 바이트 또는 6 바이트로 결정될 수 있다.

포인터 포맷으로, 수집 메시지 사이즈는 c + pop(x)lg(x) / 8 바이트로 결정될 수 있다(lg는 밑이 2인 로그에 대한 심볼). 포인터는 MAU 입도 x의 주어진 비트맵에서 각각의 제거된 블록을 나타내는데 사용될 수 있기 때문에, 군집 개수 함수 pop(x)는 또한 비트맵에 의해 가리켜지는 제거된 블록을 나타내는데에 사용되는 포인터의 양을 나타낼 수 있다. 또한, lg(x)는 각각의 포인터를 나타내는데에 사용되는 비트의 수를 나타낼 수 있다. 예를 들어, 도 2에 도시된 포인터 포맷에서 수집 메시지 부분의 사이즈는 포인터 포맷에 대한 총계 부분(222)에 도시된 바와 같이 4 바이트 + 5 바이트 x lg(16)/8 바이트 또는 6.5 바이트로 결정될 수 있다.

또한, 캐시로부터 제거되는 총 N개의 깨끗한 블록이 있다고 가정한다. 따라서, 전송될 메시지의 수는 N / pop(x), 즉 x개의 블록의 입도의 비트맵의 군집 개수의 평균 값에 의해 나누어진 깨끗한 블록의 수로 결정될 수 있다. 비트맵에 대한 총 트래픽(Traffic_Bitmap)은 수집 메시지의 사이즈에 의해 곱하여진 전송된 제거 메시지의 수의 곱으로서 나타내어질 수 있고,

또는 포인터 포맷으로,

로서 (바이트의 수로) 표현될 수 있다.

여기에 설명되는 기술은 트래픽의 값을 최소화하도록 구성될 수 있다. 수학식 1에서, 군집 개수 함수 pop(x)는 알려지지 않은(unknown) 것이다. 군집 개수 함수는 제거의 공간 구역성(spatial locality)의 관점에서 애플리케이션의 특징(예컨대, 제거된 블록이 인접한 주소로부터인지 여부)에 의존할 수 있다. 제거 공간 구역성은 미스 스트림(miss stream)이 아닌 제거 스트림에 기초하기 때문에 제거 공간 구역성은 캐시 공간 구역성과 다르다. 제거 공간 구역성이 완전한 경우, 군집 개수 함수는 항등 함수(identity function)이며, 여기서 pop(x) = x이다. 항등 함수는 임의의 수집 단위 입도에서 그 단위 입도 내 모든 블록이 특정 시간 주기 내에(예컨대, 단위가 수집 테이블(302) 내에 상주하는 시간 내에) 제거됨을 가리킨다. 제거 공간 구역성이 존재하지 않는 최악의 경우의 시나리오에서, 군집 개수 함수는 pop(x) = 1로서 결정될 수 있으며, 이는 입도가 어떠하든지 그 입도 단위에서 제거되는 하나의 블록이 존재함을 의미할 것이다. 아마 x가 작을 경우 실제 제거 공간 구역성은 높으나 x가 증가함에 따라 감소하고, 그 예시는 도 8에 도시되고 이하에서 설명된다.

도 8은 여기에 제시되는 적어도 일부 실시예에 따라 배열되는, 전통적인 디렉토리 프로토콜을 이용하는 트래픽, 비트맵 포맷으로의 수집을 이용하는 트래픽, 및 포인터 포맷으로의 수집을 이용하는 트래픽의 예시적인 비교를 도시하는 그래프(800)이다. 그래프(800)는 군집 개수 함수가 pop(x) = lg(x)로서 결정된다고 가정하고 세개의 기법 하의 트래픽 - 원래 트래픽(제거 통지의 수집 없음)(802) 대 트래픽-포인터(포인터 포맷을 사용하는 수집)(804) 대 트래픽-비트맵(비트맵 포맷을 사용하는 수집)(806) - 을 보여준다. 그래프(800)에서, x 축은 단위 입도를 블록 수로 나타내고, y 축은 각각의 제거에 대한 트래픽을 (바이트로) 나타낸다. 그래프(800)는 각각 808 및 810으로 도시된 트래픽-포인터 및 트래픽-비트맵에 대한 최악의 경우도 도시한다. 그래프(800)는 x의 값에 관계 없이 군집 개수 함수가 2의 값으로 유지되는(예컨대, pop(x) = 2) 예시적인 최악의 경우의 시나리오도 도시한다.

그래프(800)로부터 다음의 관찰이 이루어질 수 있다. 첫째, 포인터(트래픽-포인터) 및 비트맵(트래픽-비트맵) 포맷은 모두 수집이 없는 전통적인 기법에 비해 상당한 양의 트래픽을 절약할 수 있다. 예를 들어, 그래프(800)에 도시된 바와 같이, 블록의 수로의 단위 입도(x)가 x = 16으로 결정되는 경우, 포인터 및 비트맵 포맷 둘 다 트래픽을 약 60-70% 범위에서 감소시킬 수 있다. 둘째, 작은 입도 단위(예컨대, x < 8)에 대해서는 포인터 포맷이 더 적은 트래픽을 초래할 수 있는 한편, 더 큰 입도 단위(예컨대, x > 8)에서는 비트맵 포맷이 더 적은 트래픽을 초래할 수 있다. 셋째, 최적의 입도는 어떠한 포맷이 사용되는지에 의존할 수 있다. 그래프(800)는 x가 클수록 트래픽-비트맵에 의해 더 적은 트래픽이 발생될 수 있음을 보여준다. 넷째, 예시적인 최악의 경우의 공간 구역성(예컨대, pop(x) = 2)에서, 더 큰 단위 입도(x) 값은 더 작은 단위 입도(x) 값보다 나쁜 트래픽을 초래할 수 있다. 이러한 경우, 트래픽-포인터에 비해 트래픽-비트맵이 x가 큰 경우 사용하기에 더 위험하다고 간주될 수 있다.

이상의 관찰로부터, 포인터 포맷이 큰 차이로 비트맵 포맷을 능가할 수 없으므로 포인터 포맷이 선택적일 수 있다고 결론짓는 것이 합리적일 수 있다. 그러나, 비트맵 포맷으로부터의 트래픽 감소는 최적의 수집 단위 입도를 달성하는 것에 의존할 수 있다.

최적의 수집 단위를 획득하기 위해, x개의 블록의 입도의 비트맵의 군집 개수 pop(x)의 평균 값이 관심이 있는 임의의 범위의 입도(x)의 값에 대해 알려져 있다고 가정한다. 위의 수학식 1을 이용하여, x개의 블록의 입도의 비트맵의 군집 개수의 측정된 평균 값이 다음의 기준:

을 충족하는 경우, 비트맵 포맷이 포인터 포맷을 능가한다고 수학적으로 유도될 수 있다. 또한, x > y인 두개의 입도 단위 x 및 y가 비교된다고 가정한다. 다음의 기준:

이 충족되는 경우, 더 큰 입도 단위를 이용하는 것이 트래픽을 감소시킬 수 있다. 결과적으로, x의 범위에 대해 군집 개수 pop(x)의 평균 값이 알려져 있는 한, 어떠한 입도 및 포맷을 사용할지 직접적으로 결정하는데에 수학식 2 및 3이 사용될 수 있다.

입도 x의 비트맵의 평균 군집 개수(예컨대, 군집 개수 함수 pop(x))를 프로파일(profile)하기 위해, 수집 테이블(302) 내 영역의 스냅샷(snapshot)이 취해질 수 있다. 예를 들어, 수집을 위해 고려될 가장 큰 영역의 랜덤(random) 샘플(예컨대, 4KB)이 제거된 블록의 가장 최근의 주소로부터의 시드(seed)를 사용하여 선택될 수 있다. 이후 수집 테이블(302)은 관심이 있는 가장 큰 영역을 형성하는 이웃하는 소영역(subregion)에 대해 프로브(probe)될 수 있다. 소영역이 발견되면, 비트맵이 복제되고 다른 소영역으로부터의 비트맵과 연결(concatenate)될 수 있다. 소영역이 발견되지 않으면, 비트맵은 연결 전에 "000...0"으로서 할당될 수 있다. 소영역의 비트맵을 연결하는 것으로부터의 최종 비트맵은 전체 영역의 비트맵을 형성한다. 그로부터, 비트맵을 동일 사이즈의 소영역으로 나누고 평균 군집 개수를 계산함으로써 군집 개수가 유도될 수 있다.

도 9는 여기에 제시되는 적어도 일부 실시예에 따라 배열되는, 군집 개수 함수 pop(x)의 예시적인 샘플링을 도시하는 도해이다. 특히, 도 9는 입도 x의 비트맵의 평균 군집 개수를 결정하기 위해 군집 개수 함수 pop(x)를 통계적으로 추정하는데에 어떻게 수집 테이블(302)이 사용될 수 있는지의 예시를 보여준다. 도시된 수집 테이블(302)은 제1 소영역(900) 및 제2 소영역(902)을 포함한다. 제1 소영역(900)은 4KB 영역에 속하는 태그 4C5FA7A0에 대응한다. 제2 소영역(902)은 역시 4KB 영역에 속하는 태그 4C5FA7A3에 대응한다. 어떠한 입도 단위 사이즈를 선택할지에 관한 판정을 고려하여 아래의 예시에서 예시적인 16 블록, 32 블록 및 64 블록의 입도 단위가 이용된다.

입도 64의 비트맵의 평균 군집 개수(예컨대, pop(64))를 계산하기 위하여, 제1 소영역(900)의 비트맵 및 제2 소영역(902)의 비트맵이 평가될 수 있다. 제1 소영역(900)의 비트맵은 16 비트 스트링 "1001001000011000"이다. 제2 소영역(902)의 비트맵은 16 비트 스트링 "0011100111001110"이다. 도시된 예시에서와 같이, 제3 소영역(904) 및 제4 소영역(906)이 각각 16 비트 스트링 "0000000000000000"으로 채워질 수 있는데, 이는 제3 소영역(904) 및 제4 소영역(906)이 아마 어떠한 제거 정보도 포함하지 않을 것이나 네개의 소영역이 하나의 제거 메시지로 수집되는 경우 트래픽에 기여할 수 있기 때문이다. 전체 64 비트 스트링의 군집 개수는 14이다. 즉, 제1 소영역(900)의 16 비트 스트링은 5개의 "1" 값을 포함하고, 제2 소영역(902)의 16 비트 스트링은 9개의 "1" 값을 포함하며, 제3 소영역(904)의 16 비트 스트링은 0개의 "1" 값을 포함하고, 제4 소영역(906)의 16 비트 스트링은 0개의 "1" 값을 포함한다. 제1 소영역(900)의 5개의 "1" 값, 제2 소영역(902)의 9개의 "1" 값 및 제3 소영역(904) 및 제4 소영역(906) 둘의 0개의 "1" 값의 합은 14이다. 따라서, 입도 64의 비트맵의 평균 군집 개수 pop(64)는 14와 같다.

입도 32의 비트맵의 평균 군집 개수(예컨대, pop(32))를 계산하기 위하여, 위에서 평가된 64 비트 스트링은 두개의 32 비트 스트링으로 갈라질 수 있다. 왼쪽 스트링(즉, "1001001000011000")은 5개의 "1" 값을 포함하므로 5의 군집 개수를 가지고, 오른쪽 스트링(즉, "011100111001110")은 9개의 "1" 값을 포함하므로 9의 군집 개수를 가진다. 왼쪽 스트링으로부터의 5개의 "1" 값과 오른쪽 스트링으로부터의 9개의 "1" 값의 합은 14이다. 따라서, 입도 32의 비트맵의 평균 군집 개수 pop(32)는 7, 즉 (5+9)/2=7과 같다.

입도 16의 비트맵의 평균 군집 개수(예컨대, pop(16))를 계산하기 위하여, 위에서 평가된 64 비트 스트링은 네개의 16 비트 스트링으로 갈라질 수 있다. 그러나, 앞서 설명한 바와 같이, 16 비트 스트링 중 둘은 수집 테이블(302)에서 발견되지 않았으며(즉, 제3 소영역(904) 및 제4 소영역(906)), 따라서 이러한 16 비트 스트링은 계산에서 제외된다. 입도 16의 비트맵의 평균 군집 개수의 계산에서 두개의 16 비트 스트링이 고려된다. 왼쪽 스트링(즉, "1001001000011000")은 5개의 "1" 값을 포함하므로 5의 군집 개수를 가지고, 오른쪽 스트링(즉, "0011100111001110")은 9의 군집 개수를 가진다. 따라서, 입도 16의 비트맵의 평균 군집 개수 pop(16)은 7, 즉 (5+9)/2=7과 같다.

군집 개수가 어떻게 사용될 수 있는지의 예시를 도시하기 위해 도 10이 부분적으로 제공된다. 도 10은 여기에 제시되는 적어도 일부 실시예에 따라 배열되는, 비트맵 포맷을 사용할지 포인터 포맷을 사용할지 여부를 결정하는데에 사용하기 위한 샘플 계산을 도시하는 표(1000)이다. 특히, 표(1000)는 입도 x의 비트맵의 평균 군집 개수(예컨대, pop(x))(두번째 열(column))가 각각의 포인터를 나타내는데에 사용되는 비트의 수(예컨대, x/lg(x))(세번째 열)와 비교되는 경우, 입도 x의 비트맵의 평균 군집 개수(예컨대, pop(x))가 더 큰 값을 가짐을 보여준다.

표(1000)의 첫번째 행(row)(1002)에서 x는 16으로 설정된다. 입도 16의 비트맵의 평균 군집 개수는 (예컨대, 도 9를 참조하여 위에서 추정된 바와 같이) 7과 같다. x가 16으로 설정되는 경우 각각의 포인터를 나타내는데에 사용되는 비트의 수는 4(예컨대, 16/4 = 4)와 같다. 따라서, x가 16으로 설정되는 경우 비트맵 포맷이 가장 트래픽을 보존하는 포맷일 수 있다.

표(1000)의 두번째 행(1004)에서 x는 32로 설정된다. 입도 32의 비트맵의 평균 군집 개수는 (예컨대, 도 9를 참조하여 위에서 추정된 바와 같이) 7과 같다. x가 32로 설정되는 경우 각각의 포인터를 나타내는데에 사용되는 비트의 수는 6.4(예컨대, 32/5 = 6.4)와 같다. 따라서, x가 32로 설정되는 경우 비트맵 포맷이 가장 트래픽을 보존하는 포맷일 수 있다.

표(1000)의 세번째 행(1006)에서 x는 64로 설정된다. 입도 64의 비트맵의 평균 군집 개수는 (예컨대, 도 9를 참조하여 위에서 추정된 바와 같이) 14와 같다. x가 64로 설정되는 경우 각각의 포인터를 나타내는데에 사용되는 비트의 수는 10.7(예컨대, 64/6 = 10.7)과 같다. 따라서, x가 64로 설정되는 경우 비트맵 포맷이 가장 트래픽을 보존하는 포맷일 수 있다.

도 11은 여기에 제시되는 적어도 일부 실시예에 따라 배열되는, 예시적인 시나리오에서 어떠한 수집 단위 입도가 가장 트래픽을 보존하는지 결정하는데에 사용하기 위한 샘플 계산을 도시하는 표(1100)이다. 특히, 표(1100)는 입도 y의 비트맵의 평균 군집 개수 pop(y)(두번째 열)가 c/pop(x)+(x-y)/8 (세번째 열)과 비교되는 경우 pop(y)가 더 큰 값을 가짐을 보여준다.

표(1100)의 첫번째 행(1102)에서 x는 32로 설정되고 y는 16으로 설정된다. 입도 16의 비트맵의 평균 군집 개수는 (예컨대, 도 9를 참조하여 위에서 추정된 바와 같이) 7과 같다. c/pop(x)+(x-y)/8의 값은 2.57(예컨대, 4/7+(32-16)/8=2.57)과 같다. 따라서, x가 32로 설정되고 y가 16으로 설정되는 경우 가장 트래픽을 보존하는 입도 단위는 16 블록 영역이다.

표(1100)의 두번째 행(1104)에서 x는 64로 설정되고 y는 16으로 설정된다. 입도 16의 비트맵의 평균 군집 개수는 (예컨대, 도 9를 참조하여 위에서 추정된 바와 같이) 7고 같다. c/pop(x)+(x-y)/8의 값은 6.29(예컨대, 4/14+(64-16)/8=6.29)와 같다. 따라서, x가 64로 설정되고 y가 16으로 설정되는 경우 가장 트래픽을 보존하는 입도 단위는 16블록 영역이다.

도 10과 도 11에 도시된 예시에 따르면, 가장 트래픽을 보존하는 포맷은 비트맵 포맷이고 가장 트래픽을 보존하는 수집 단위는 16 블록 입도 단위라고 결정될 수 있다. 따라서, 도 9에서 묘사되고 위에서 설명된 예시에 대하여, 제거 메시지 수집은 비트맵 포맷으로 16 블록 영역을 사용하여야 한다.

도 12는 여기에 제시되는 적어도 일부 실시예에 따라 배열되는, 수집 입도 단위를 결정하기 위한 예시적인 프로세스를 도시하는 흐름도이다. 프로세스(1200)는 하나 이상의 블록(1202-1210)에 의해 도시된 다양한 동작, 기능 또는 작용을 포함할 수 있다.

프로세스(1200)는 블록 1202(비트맵의 현재 입도에 대한 군집 개수 결정)에서 시작할 수 있으며, 여기에서 MAU(128)는 비트맵의 현재 입도에 대한 군집 개수를 결정하도록 구성될 수 있다. 블록 1202에 블록 1204가 뒤따를 수 있다.

블록 1204(비트맵의 제안된 입도에 대한 군집 개수 결정)에서, MAU(128)는 비트맵의 제안된 입도에 대한 군집 개수를 결정하도록 구성될 수 있다. 블록 1204에 블록 1206이 뒤따를 수 있다.

블록 1206(입도 단위를 비교하기 위한 기준 충족)에서, MAU(128)는 현재 입도와 제안된 입도를 비교하기 위한 기준이 충족되는지 여부를 결정하도록 구성될 수 있다. 앞서 설명한 바와 같이, x > y인 두개의 입도 단위 x 및 y가 비교될 수 있다. 또한, 앞서 설명한 바와 같이, 수학식 3에 특정된 기준이 충족되는 경우 더 큰 입도 단위를 이용하는 것이 트래픽을 감소시킨다. 블록 1206에서, MAU(128)는 수학식 3에 특정된 부등식이 충족되는지 여부(즉, pop(x) > c / (pop (x)) + (x - y) / 8인지 여부)를 결정하도록 구성될 수 있다. 이 예시에서, MAU(128)가 수학식 3에 특정된 부등식이 충족된다고 결정하는 경우 프로세스(1200)는 블록 1206에서 블록 1208로 진행할 수 있다. 그러나, MAU(128)가 수학식 3에 특정된 부등식이 충족되지 않는다고 결정하는 경우 프로세스(1200)는 블록 1206에서 블록 1210으로 진행할 수 있다.

블록 1208(현재 입도에서 제안된 입도로 비트맵 재구성)에서, MAU(128)는 현재 입도에서 제안된 입도로 비트맵을 재구성하도록 구성될 수 있다. 블록 1208 후에, 프로세스(1200)는 (예컨대, 주기적으로, 계속적으로, 또는 요구에 따라) 반복할 수 있거나, 종료할 수 있다.

블록 1210(비트맵의 현재 입도 유지)에서, MAU(128)는 비트맵의 현재 입도를 유지하도록 구성될 수 있다. 블록 1210 후에, 프로세스는 (예컨대, 주기적으로, 계속적으로, 또는 요구에 따라) 반복할 수 있거나, 종료할 수 있다.

도 13은 여기에 제시되는 적어도 일부 실시예에 따라 배열되는 예시적인 컴퓨팅 장치를 위한 컴퓨터 하드웨어 아키텍쳐를 도시하는 블록도이다. 도시된 바와 같이, 컴퓨터(1300)는 프로세서(1310), 메모리(1320) 및 하나 이상의 드라이브(1330)를 포함한다. 컴퓨터(1300)는 통상적인 컴퓨터 시스템, 내장형(embedded) 제어 컴퓨터, 랩탑 컴퓨터, 서버 컴퓨터, 모바일 장치, 셋탑 박스, 키오스크(kiosk), 차량 정보 시스템, 모바일 전화, 주문형(customized) 머신 또는 다른 하드웨어 플랫폼으로 구현될 수 있다.

프로세서(1310)는 도 1을 참조하여 위에서 설명된 멀티코어 칩(102)와 같이 구성될 수 있다. 특히, 프로세서(1310)는 복수의 프로세싱 코어를 포함할 수 있으며, 그 각각은 캐시 메모리(106)고 같은 하나 이상의 캐시 메모리에 동작적으로 결합될 수 있다. 도시된 예시에서, 캐시 메모리(106), 디렉토리 컨트롤러(118) 및 디렉토리(120)는 프로세서(1310)에 동작적으로 결합될 수 있다. 대안적으로, 이러한 컴포넌트들은 프로세서(1310) 상에 온칩일 수 있다. 디렉토리 컨트롤러(118)는 또한 위에서 설명된 메모리(116)와 같이 구성될 수 있는 메모리(1320)와 통신하도록 구성될 수 있다. 디렉토리(120)는 프로세서(1310) 내에서 다수의 디렉토리에 걸쳐 분산되거나 단일 디렉토리로서 구현될 수 있다.

드라이브(1330) 및 그 연관된 컴퓨터 저장 매체는 컴퓨터 판독 가능 명령어, 데이터 구조, 프로그램 모듈 및 컴퓨터(1300)에 대한 다른 데이터의 저장을 제공한다. 드라이브(1330)는 운영 체제(1340), 애플리케이션 프로그램(1350), 프로그램 모듈(1360) 및 데이터베이스(1380)를 포함할 수 있다. 컴퓨터(1300)는 사용자 입력 장치(1390)를 더 포함하며, 이를 통하여 사용자는 명령 및 데이터를 입력할 수 있다. 입력 장치(1390)는 전자 디지타이저, 마이크로폰, 키보드, 및 보통 마우스, 트랙볼 또는 터치 패드로 지칭되는 포인팅 장치 중 하나 이상을 포함할 수 있다. 다른 입력 장치는 조이스틱, 게임 패드, 위성 접시, 스캐너, 기타 장치 등을 포함할 수 있다.

이러한 입력 장치 및 다른 입력 장치는 시스템 버스에 결합되는 사용자 입력 인터페이스를 통하여 프로세서(1310)에 결합될 수 있으나, 병렬 포트, 게임 포트 또는 범용 직렬 버스(universal serial bus(USB))와 같은 다른 인터페이스 및 버스 구조에 의해 결합될 수 있다. 컴퓨터(1300)와 같은 컴퓨터는 또한 출력 주변장치 인터페이스(1394) 등을 통하여 결합될 수 있는 스피커, 프린터, 디스플레이 및/또는 다른 장치와 같은 다른 주변 출력 장치를 포함할 수 있다.

컴퓨터(1300)는 네트워크 인터페이스(1396)에 결합된 네트워크(1308)와 통신하거나 그 일부로서 동작하는 원격 컴퓨터(미도시) 및/또는 다른 장치와 같은 하나 이상의 컴퓨터로의 논리적 연결을 사용하여 네트워크 환경에서 동작할 수 있다. 원격 컴퓨터는 개인용 컴퓨터, 서버 컴퓨터, 라우터, 네트워크 PC, 피어 장치 또는 다른 공통 네트워크 노드일 수 있고, 컴퓨터(1300)에 관하여 위에서 설명한 요소 중 다수 또는 전부를 포함할 수 있다. 네트워킹 환경은 사무실, 기업 광역 통신망("WAN"), 근거리 통신망("LAN"), 인트라넷 및 인터넷에서 흔하다.

LAN 또는 WLAN 네트워킹 환경에서 사용되는 경우, 컴퓨터(1300)는 네트워크 인터페이스(1396) 또는 어댑터를 통하여 LAN에 결합될 수 있다. WAN 네트워킹 환경에서 사용되는 경우, 컴퓨터(1300)는 보통 모뎀 또는 네트워크(1308) 또는 인터넷과 같은 WAN을 통하여 통신을 수립하기 위한 다른 수단을 포함한다. WAN은 인터넷, 예시된 네트워크(1308), 다양한 다른 네트워크 또는 그들의 임의의 조합을 포함할 수 있다. 컴퓨터 간의 통신 링크, 링, 메쉬, 버스, 클라우드 또는 네트워크를 수립하는 다른 메커니즘이 사용될 수 있음이 인정될 것이다.

일부 실시예에 따르면, 컴퓨터(1300)는 네트워킹 환경에 결합될 수 있다. 컴퓨터(1300)는 드라이브(1330) 또는 다른 저장 장치와 연관된 물리적인 컴퓨터 판독 가능 저장 매체(들) 중 하나 이상의 예시를 포함할 수 있다. 시스템 버스는 프로세서(1310)가 코드 및/또는 데이터를 컴퓨터 저장 매체로/로부터 판독하는 것이 가능하도록 할 수 있다. 매체는 반도체, 자기성 재료, 광학 매체, 전기 저장 장치, 전기화학 저장 장치 또는 임의의 다른 그러한 저장 기술을 포함하지만 이에 제한되지 않는 임의의 적절한 기술을 이용하여 구현되는 저장 요소의 형태의 장치를 나타낼 수 있다. 매체는 RAM, ROM, 플래시 또는 다른 유형의 휘발성 또는 비휘발성 메모리 기술로서 특징지어지든 아니든, 메모리(1320)와 연관된 컴포넌트를 나타낼 수 있다. 매체는 또한 저장 드라이브(1330)로 구현되든 아니든 2차 저장 장치를 나타낼 수 있다. 하드 드라이브 구현예는 고체 상태(solid state)로서 특징지어질 수 있거나 자기적으로 인코딩된 정보를 저장하는 회전 매체를 포함할 수 있다.

저장 매체는 하나 이상의 프로그램 모듈(1360)을 포함할 수 있다. 프로그램 모듈(1360)은 프로세서(1310)로 로딩되고 실행되는 경우, 범용 컴퓨팅 시스템을 특수 목적 컴퓨팅 시스템으로 변환하는 소프트웨어 명령어를 포함할 수 있다. 본 설명 전반을 통하여 상세하게 설명되는 바와 같이, 프로그램 모듈(1360)은 다양한 툴(tool) 또는 기법을 제공할 수 있고, 이에 따라 컴퓨터(1300)는 여기에서 설명되는 컴포넌트, 논리 흐름 및/또는 데이터 구조를 사용하여 전체적인 시스템 또는 동작 환경 내에 참여할 수 있다.

프로세서(1310)는 개별적으로 또는 집합적으로 임의의 수의 상태를 가정할 수 있는, 임의의 수의 트랜지스터 또는 기타 회로 소자로부터 구성될 수 있다. 더 구체적으로, 프로세서(1310)는 상태 머신 또는 유한 상태 머신으로 동작할 수 있다. 그러한 머신은 프로그램 모듈(1360) 내에 포함된 실행 가능한 명령어를 로딩함으로써 특정 머신 또는 제2 머신으로 변환될 수 있다. 이러한 컴퓨터 실행 가능 명령어는, 프로세서(1310)가 어떻게 상태 간에 전환하는지를 특정함으로써 프로세서(1310)를 변환할 수 있고, 이에 따라 제1 머신으로부터 제2 머신으로 프로세서(1310)를 구성하는 트랜지스터 또는 기타 회로 소자를 변환할 수 있다. 각각의 머신의 상태는 또한 하나 이상의 사용자 입력 장치(1390), 네트워크 인터페이스(1396), 기타 주변장치, 기타 인터페이스, 또는 하나 이상의 사용자 또는 기타 행위자로부터 입력을 수신함으로써 변환될 수 있다. 각각의 머신은 또한 프린터, 스피커, 비디오 디스플레이 등과 같은 다양한 출력 장치의 다양한 물리적인 특징 또는 상태를 변환할 수 있다.

프로그램 모듈(1360)을 인코딩하는 것은 또한 저장 매체의 물리적 구조를 변환할 수 있다. 본 설명의 상이한 구현예에서, 물리적 구조의 특정 변환은 다양한 요소에 의존할 수 있다. 그러한 요소의 예시는, 저장 매체를 구현하는데 사용되는 기술, 저장 매체가 주 저장장치로 특징지어지는지 또는 이차적인 저장장치로 특징지어지는지 여부 등을 포함할 수 있으나, 이에 제한되지는 않는다. 예를 들어, 저장 매체가 반도체 기반의 메모리로 구현되는 경우, 프로그램 모듈(1360)은 소프트웨어가 거기에 인코딩되면 반도체 메모리(1320)의 물리적 상태를 변환할 수 있다. 예를 들어, 소프트웨어는 반도체 메모리(1320)를 구성하는 트랜지스터, 커패시터, 또는 기타 이산 회로 소자의 상태를 변환할 수 있다.

다른 예시로서, 저장 매체는 드라이브(1330)와 같은 자기 또는 광학 기술을 사용하여 구현될 수 있다. 그러한 구현예에서, 프로그램 모듈(1360)은 소프트웨어가 거기에 인코딩되면, 자기 또는 광학 매체의 물리적인 상태를 변환할 수 있다. 이러한 변환은 주어진 자기 매체 내에서 특정 위치의 자기적인 특징을 바꾸는 것을 포함할 수 있다. 이러한 변환은 또한 주어진 광학 매체 내에서 특정 위치의 물리적인 특성 또는 특징을 바꾸어, 그 위치의 광학적인 특징을 바꾸는 것을 포함할 수 있다. 본 설명의 범위 및 사상으로부터 벗어나지 않으면서 물리적 매체의 다양한 다른 변환이 가능하다는 것이 인식되어야 한다. 청구범위에서 사용되는 "컴퓨터 저장 매체"라는 구절 및 그 변형은 파동, 신호 및/또는 기타 일시적(transitory)인 및/또는 무형(intangible)의 통신 매체를 그 자체로는(per se) 포함하지 않는다.

도 14는 여기에 제시되는 적어도 일부 실시예에 따르는, 컴퓨팅 장치 상에서 컴퓨터 프로세스를 실행하기 위한 컴퓨터 프로그램을 포함하는 컴퓨터 프로그램 제품(1400)을 도시하는 개략도이다. 예시적인 컴퓨터 프로그램 제품(1400)의 예시적인 실시예가 신호 포함 매체(1402)를 사용하여 제공되며, 적어도 하나의 명령어(1404)를 포함할 수 있다. 적어도 하나의 명령어(1404)는, 멀티코어 칩에서 캐시 메모리의 제1 복수의 연속적인 블록 주소로부터 제1 복수의 깨끗한 블록의 제1 제거를 검출하기 위한 하나 이상의 명령어, 캐시 메모리의 제2 복수의 연속적인 블록 주소로부터 제2 복수의 깨끗한 블록의 제2 제거를 검출하기 위한 하나 이상의 명령어, 제1 복수의 깨끗한 블록의 제1 제거를 반영하도록 멀티코어 칩 내 수집 테이블의 제1 엔트리를 갱신하기 위한 하나 이상의 명령어, 제2 복수의 깨끗한 블록의 제2 제거를 반영하도록 멀티코어 칩 내 수집 테이블의 제2 엔트리를 갱신하기 위한 하나 이상의 명령어, 수집 테이블의 제1 엔트리에 반영된 제1 복수의 깨끗한 블록의 제1 제거를 특정하도록 구성되는 제1 수집 메시지를 생성하기 위한 하나 이상의 명령어, 수집 테이블의 제2 엔트리에 반영된 제2 복수의 깨끗한 블록의 제2 제거를 특정하도록 구성되는 제2 수집 메시지를 생성하기 위한 하나 이상의 명령어, 또는 멀티코어 칩 내 디렉토리에 결합되는 디렉토리 컨트롤러로 제1 수집 메시지 및 제2 수집 메시지를 전송하기 위한 하나 이상의 명령어를 포함할 수 있다.

일부 실시예에서, 하나 이상의 컴퓨터 프로그램 제품(1400)의 신호 포함 매체(1402)는 컴퓨터 판독 가능 매체(1406), 기록 가능 매체(1408), 및/또는 통신 매체(1410)를 포함한다.

여기에서 설명된 대상이 컴퓨터 시스템 상의 운영 체제 및 어플리케이션 프로그램의 실행과 함께 실행하는 프로그램 모듈의 일반적인 맥락에서 제시되고 있으나, 당업자는 다른 구현예가 다른 유형의 프로그램 모듈과 조합하여 수행될 수 있다는 것을 인식할 것이다. 일반적으로, 프로그램 모듈은, 루틴, 프로그램, 컴포넌트, 데이터 구조 및 특정 태스크를 수행하거나 특정한 추상 데이터 유형(abstract data type)을 구현하는 기타 유형의 구조를 포함한다. 또한, 당업자는 여기에서 설명된 대상이 휴대용 장치, 멀티 코어 프로세서 시스템, 마이크로프로세서 기반 또는 프로그램 가능한 가전, 미니컴퓨터, 메인프레임 컴퓨터 등을 포함하는 다른 컴퓨터 시스템 구성으로 실시될 수 있다는 것을 인정할 것이다.

본 개시는 다양한 태양의 예시로서 의도된 본 출원에 기술된 특정 실시예들에 제한되지 않을 것이다. 당업자에게 명백할 바와 같이, 많은 수정과 변형들이 그 사상과 범위를 벗어나지 않으면서 이루어질 수 있다. 여기에 열거된 것들에 더하여, 본 개시의 범위 안에서 기능적으로 균등한 방법과 장치가 위의 설명으로부터 당업자에게 명백할 것이다. 그러한 수정과 변형들은 첨부된 청구항의 범위에 들어가도록 의도된 것이다. 본 개시는 첨부된 청구항과 그러한 청구항에 부여된 균등물의 전 범위에 의해서만 제한될 것이다. 본 개시가 물론 다양할 수 있는 특정 방법, 시약, 합성 구성 또는 생물학적 시스템에 제한되지 않는 것으로 이해될 것이다. 또한, 여기에서 사용된 용어는 특정 실시예를 기술하기 위한 목적이고, 제한하는 것으로 의도되지 않음이 이해될 것이다.

여기에서 실질적으로 임의의 복수 및/또는 단수의 용어의 사용에 대하여, 당업자는 맥락 및/또는 응용에 적절하도록, 복수를 단수로 및/또는 단수를 복수로 해석할 수 있다. 다양한 단수/복수의 치환은 명확성을 위해 여기에서 명시적으로 기재될 수 있다.

당업자라면, 일반적으로 본 개시에 사용되며 특히 첨부된 청구범위(예를 들어, 첨부된 청구범위)에 사용된 용어들이 일반적으로 "개방적(open)" 용어(예를 들어, 용어 "포함하는"은 "포함하지만 이에 제한되지 않는"으로, 용어 "갖는"는 "적어도 갖는"으로, 용어 "포함하다"는 "포함하지만 이에 한정되지 않는" 등으로 해석되어야 함)로 의도되었음을 이해할 것이다. 또한, 당업자라면, 도입된 청구항의 기재사항의 특정 수가 의도된 경우, 그러한 의도가 청구항에 명시적으로 기재될 것이며, 그러한 기재사항이 없는 경우, 그러한 의도가 없음을 또한 이해할 것이다. 예를 들어, 이해를 돕기 위해, 이하의 첨부 청구범위는 "적어도 하나" 및 "하나 이상" 등의 도입 구절의 사용을 포함하여 청구항 기재사항을 도입할 수 있다. 그러나, 그러한 구절의 사용이, 부정관사 "하나"("a" 또는 "an")에 의한 청구항 기재사항의 도입이, 그러한 하나의 기재사항을 포함하는 실시예로, 그러한 도입된 청구항 기재사항을 포함하는 특정 청구항을 제한함을 암시하는 것으로 해석되어서는 안되며, 동일한 청구항이 도입 구절인 "하나 이상" 또는 "적어도 하나" 및 "하나"("a" 또는 "an")과 같은 부정관사(예를 들어, "하나"는 "적어도 하나" 또는 "하나 이상"을 의미하는 것으로 일반적으로 해석되어야 함)를 포함하는 경우에도 마찬가지로 해석되어야 한다. 이는 청구항 기재사항을 도입하기 위해 사용된 정관사의 경우에도 적용된다. 또한, 도입된 청구항 기재사항의 특정 수가 명시적으로 기재되는 경우에도, 당업자라면 그러한 기재가 일반적으로 적어도 기재된 수(예를 들어, 다른 수식어가 없는 "두 개의 기재사항"을 단순히 기재한 것은, 일반적으로 적어도 두 개의 기재사항 또는 두 개 이상의 기재사항을 의미함)를 의미하도록 해석되어야 함을 이해할 것이다. 또한, "A, B 및 C 등 중의 적어도 하나"와 유사한 규칙이 사용된 경우에는, 일반적으로 그러한 해석은 당업자가 그 규칙을 이해할 것이라는 전제가 의도된 것이다(예를 들어, "A, B 및 C 중의 적어도 하나를 갖는 시스템"은, A만을 갖거나, B만을 갖거나, C만을 갖거나, A 및 B를 함께 갖거나, A 및 C를 함께 갖거나, B 및 C를 함께 갖거나, A, B, 및 C를 함께 갖는 시스템을 포함하지만 이에 제한되지 않음). 또한 당업자라면, 실질적으로 어떠한 이접 접속어(disjunctive word) 및/또는 두 개 이상의 대안적인 용어들을 나타내는 구절은, 그것이 상세한 설명, 청구범위 또는 도면에 있는지와 상관없이, 그 용어들 중의 하나, 그 용어들 중의 어느 하나, 또는 그 용어들 두 개 모두를 포함하는 가능성을 고려했음을 이해할 것이다. 예를 들어, "A 또는 B"라는 구절은 "A" 또는 "B" 또는 "A 및 B"의 가능성을 포함하는 것으로 이해될 것이다.

또한, 마쿠쉬 그룹을 이용하여 본 개시의 특징 또는 양상이 기술될 때는, 당업자라면 본 개시가 또한 마쿠쉬 그룹의 임의의 개별 구성원 또는 구성원의 서브그룹을 이용하여 기술됨을 이해할 것이다.

서면의 기재를 제공하는 것과 같은 어떠한 그리고 모든 목적을 위해서, 본 개시에 기재된 모든 범위는 모든 어떠한 가능한 하위범위 및 그 하위범위의 조합을 또한 포괄함이 이해 되어야 한다. 임의의 나열된 범위는, 그 동일한 범위가 적어도 동일한 이분 범위, 삼분 범위, 사분 범위, 오분 범위, 십분 범위 등으로 분할될 수 있으며, 그러한 동일 범위를 충분히 기술하는 것으로 용이하게 인식될 수 있다. 제한되지 않은 예로서, 본 개시에 기재된 각 범위는, 하위 삼분, 중간 삼분, 상위 삼분 등으로 용이하게 분할될 수 있다. 또한, "까지(up to)," "적어도(at least)," "더 큰(greater than)," "더 적은(less than)" 등과 같은 모든 언어는 인용된 수를 포함하며, 상술한 바와 같은 하위 범위로 분할될 수 있는 범위들을 나타냄이 이해되어야 한다. 마지막으로, 범위는 각 개별 구성요소를 포함됨이 이해되어야 한다. 따라서, 예를 들어, 1 내지 3 셀(cell)을 가지는 그룹은 1, 2 또는 3 셀을 가지는 그룹을 나타낸다. 유사하게, 1 내지 5 셀을 가지는 그룹은 1, 2, 3, 4 또는 5 셀을 가지는 그룹을 나타내는 등이다.

다양한 양상 및 실시예들이 본 개시에서 기술되었지만, 다른 양상 및 실시예들이 당업자에게 명확할 것이다. 본 개시에 기재된 다양한 양상 및 실시예는 예시의 목적으로 제시된 것이고, 제한하려고 의도된 것은 아니며, 진정한 범위 및 사상은 이하 청구범위에 의해 나타낸다.

Claims (33)

1. 멀티코어 칩(multicore chip)에서 캐시 제거 통지(cache eviction notification)를 디렉토리(directory)에 수집(aggregate)하기 위한 컴퓨터 구현 방법으로서,
   컴퓨팅 장치에 의하여, 적어도 하나의 캐시 메모리의 복수의 블록 주소로부터 복수의 블록의 제거를 반영하도록 수집 테이블(aggregation table)을 갱신하는 단계;
   상기 컴퓨팅 장치에 의하여, 상기 수집 테이블에 반영된 상기 복수의 블록의 상기 제거를 특정하도록 구성되는 수집 메시지(aggregate message)를 생성하는 단계; 및
   상기 수집 메시지를 상기 디렉토리로 전송하는 단계
   를 포함하고,
   상기 디렉토리는 상기 수집 메시지를 파스(parse)하고 상기 수집 메시지에 특정된 상기 적어도 하나의 캐시 메모리로부터의 상기 제거를 반영하도록 복수의 디렉토리 엔트리(entry)를 갱신하도록 구성되는,
   컴퓨터 구현 방법.
2. 제1항에 있어서,
   상기 적어도 하나의 캐시 메모리의 상기 복수의 블록 주소로부터 상기 복수의 블록의 제거를 반영하도록 상기 수집 테이블을 갱신하는 단계는, 상기 컴퓨팅 장치에 의하여, 상기 적어도 하나의 캐시 메모리의 상기 복수의 블록 주소로부터 하나 이상의 깨끗한 블록(clean block)의 제거를 반영하도록 상기 수집 테이블을 갱신하는 단계를 포함하는, 컴퓨터 구현 방법.
3. 제2항에 있어서,
   상기 컴퓨팅 장치에 의하여, 상기 적어도 하나의 캐시 메모리의 상기 복수의 블록 주소로부터 하나 이상의 오염된 블록(dirty block)의 제거를 무시하는 단계를 더 포함하는 컴퓨터 구현 방법.
4. 제1항에 있어서,
   상기 수집 메시지에 특정된 상기 적어도 하나의 캐시 메모리로부터의 상기 제거를 반영하도록 상기 복수의 디렉토리 엔트리를 갱신하기 위하여,
   상기 컴퓨팅 장치에 의하여, 상기 적어도 하나의 캐시 메모리의 블록 주소로부터 블록의 제거를 검출하는 단계;
   상기 컴퓨팅 장치에 의하여, 상기 수집 테이블이 상기 블록 주소에 대응하는 엔트리를 포함하는지 여부를 결정하는 단계;
   상기 수집 테이블이 상기 블록 주소에 대응하는 상기 엔트리를 포함하지 않는다는 결정에 응답하여, 상기 컴퓨팅 장치에 의하여, 상기 수집 테이블 내 상기 엔트리를 생성하고 상기 블록 주소로부터 상기 블록의 상기 제거를 반영하도록 상기 엔트리를 갱신하는 단계; 및
   상기 수집 테이블이 상기 블록 주소에 대응하는 상기 엔트리를 포함한다는 결정에 응답하여, 상기 컴퓨팅 장치에 의하여, 상기 블록 주소로부터 상기 블록의 상기 제거를 반영하도록 상기 엔트리를 갱신하는 단계
   를 포함하는, 컴퓨터 구현 방법.
5. 제4항에 있어서,
   상기 엔트리는 태그(tag) 부분 및 비트맵(bitmap) 부분을 포함하고, 상기 비트맵 부분 내 각각의 비트는 복수의 연속적인 블록 주소 중 하나에 대응하고, 각각의 비트의 제1 비트 값은 상기 복수의 연속적인 블록 주소 내 적용 가능한(applicable) 블록 주소로부터 블록이 제거되었음을 가리키며, 각각의 비트의 제2 비트 값은 상기 복수의 연속적인 블록 주소 내 적용 가능하지 않은 블록 주소로부터 상기 블록이 제거되지 않았음을 가리키는, 컴퓨터 구현 방법.
6. 제5항에 있어서,
   상기 태그 부분은 상기 적용 가능한 블록 주소의 부분을 포함하고, 상기 디렉토리는 상기 비트맵 부분으로부터의 데이터와 상기 태그 부분을 연결(concatenating)함으로써 상기 적용 가능한 블록 주소를 결정하고 상기 적용 가능한 블록 주소로부터 상기 블록의 제거를 반영하도록 상기 복수의 디렉토리 엔트리 중 하나를 갱신하도록 구성되는, 컴퓨터 구현 방법.
7. 제5항에 있어서,
   상기 수집 테이블에 반영된 상기 복수의 블록의 상기 제거를 특정하도록 구성되는 상기 수집 메시지를 생성하는 단계는,
   상기 컴퓨팅 장치에 의하여, 상기 수집 테이블로부터 상기 태그 부분 및 상기 비트맵 부분을 회수(retrieving)하는 단계; 및
   상기 컴퓨팅 장치에 의하여, 상기 태그 부분 및 상기 비트맵 부분을 포함하는 상기 수집 메시지를 생성하는 단계
   를 포함하는, 컴퓨터 구현 방법.
8. 제5항에 있어서,
   상기 수집 테이블에 반영된 상기 복수의 블록의 상기 제거를 특정하도록 구성되는 상기 수집 메시지를 생성하는 단계는,
   상기 컴퓨팅 장치에 의하여, 상기 수집 테이블로부터 상기 태그 부분 및 상기 비트맵 부분을 회수하는 단계;
   상기 컴퓨팅 장치에 의하여, 상기 태그 부분 및 상기 비트맵 부분을 포함하는 제1 수집 메시지를 생성하는 단계;
   상기 컴퓨팅 장치에 의하여, 상기 비트맵 부분을 상기 제1 비트 값을 가지는 상기 비트맵 부분 내 복수의 비트에 대응하는 복수의 포인터(pointer) 값으로 전환하는 단계; 및
   상기 컴퓨팅 장치에 의하여, 상기 태그 부분 및 상기 복수의 포인터 값을 포함하는 제2 수집 메시지를 생성하는 단계
   를 포함하는, 컴퓨터 구현 방법.
9. 제8항에 있어서,
   상기 태그 부분은 상기 적용 가능한 블록 주소의 부분을 포함하고, 상기 디렉토리는 상기 복수의 포인터 값 중 하나와 상기 태그 부분을 연결함으로써 상기 적용 가능한 블록 주소를 결정하고 상기 적용 가능한 블록 주소로부터 상기 블록의 제거를 반영하도록 상기 복수의 디렉토리 엔트리 중 하나를 갱신하도록 구성되는, 컴퓨터 구현 방법.
10. 제8항에 있어서,
    상기 수집 메시지를 상기 디렉토리로 전송하는 단계는,
    상기 컴퓨팅 장치에 의하여, 상기 제1 수집 메시지가 상기 제2 수집 메시지보다 더 작은 데이터 사이즈를 가지는지 여부를 결정하는 단계;
    상기 제1 수집 메시지가 상기 제2 수집 메시지보다 더 작은 데이터 사이즈를 가진다는 결정에 응답하여, 상기 제1 수집 메시지를 상기 디렉토리로 전송하는 단계 - 상기 디렉토리는 상기 제1 수집 메시지를 파스하고 상기 제1 수집 메시지에 특정된 상기 적어도 하나의 캐시 메모리로부터의 상기 제거를 반영하도록 상기 복수의 디렉토리 엔트리를 갱신하도록 구성됨 - ; 및
    상기 제1 수집 메시지가 상기 제2 수집 메시지보다 더 작은 데이터 사이즈를 가지지 않는다는 결정에 응답하여, 상기 제2 수집 메시지를 상기 디렉토리로 전송하는 단계 - 상기 디렉토리는 상기 제2 수집 메시지를 파스하고 상기 제2 수집 메시지에 특정된 상기 적어도 하나의 캐시 메모리로부터의 상기 제거를 반영하도록 상기 복수의 디렉토리 엔트리를 갱신하도록 구성됨 -
    를 포함하는, 컴퓨터 구현 방법.
11. 제5항에 있어서,
    상기 컴퓨팅 장치에 의하여, 상기 비트맵 부분의 현재 입도(granularity)에 대한 군집 개수(popcount)를 결정하는 단계;
    상기 컴퓨팅 장치에 의하여, 상기 비트맵 부분의 제안된 입도에 대한 군집 개수를 결정하는 단계; 및
    상기 컴퓨팅 장치에 의하여, 상기 군집 개수들에 기초하여, 상기 현재 입도 및 상기 제안된 입도를 비교하기 위한 기준이 충족되는지 여부를 결정하는 단계
    를 더 포함하는 컴퓨터 구현 방법.
12. 제11항에 있어서,
    상기 컴퓨팅 장치에 의하여, 상기 비트맵 부분의 상기 현재 입도에 대한 상기 군집 개수를 결정하는 단계는 상기 비트맵 부분의 현재 입도 x에 대한 군집 개수 pop(x)를 결정하는 단계를 포함하고,
    상기 컴퓨팅 장치에 의하여, 상기 비트맵 부분의 상기 제안된 입도에 대한 상기 군집 개수를 결정하는 단계는 상기 비트맵 부분의 제안된 입도 y에 대한 군집 개수 pop(y)를 결정하는 단계를 포함하며,
    상기 컴퓨팅 장치에 의하여, 상기 현재 입도 및 상기 제안된 입도를 비교하기 위한 상기 기준이 충족되는지 여부를 결정하는 단계는 부등식

    

    이 충족되는지 여부를 결정하는 단계 - c는 루트(root)의 사이즈 및 패킷 헤더와 에러 정정/검출 코드를 위해 사용되는 추가적인 비트를 나타내는 상수임 - 를 포함하는, 컴퓨터 구현 방법.
13. 제12항에 있어서,
    상기 부등식

    

    이 충족된다는 결정에 응답하여, 상기 컴퓨팅 장치에 의하여, 상기 현재 입도로부터 상기 제안된 입도로 상기 비트맵 부분을 재구성하는 단계를 더 포함하는 컴퓨터 구현 방법.
14. 제12항에 있어서,
    상기 부등식

    

    이 충족되지 않는다는 결정에 응답하여, 상기 컴퓨팅 장치에 의하여, 상기 비트맵 부분의 상기 현재 입도를 유지하는 단계를 더 포함하는 컴퓨터 구현 방법.
15. 멀티코어 칩으로서,
    복수의 코어;
    상기 복수의 코어에 결합되는 캐시 메모리;
    디렉토리 및 상기 디렉토리 및 상기 캐시 메모리에 결합되는 디렉토리 컨트롤러;
    복수의 엔트리를 포함하는 수집 테이블; 및
    상기 수집 테이블, 상기 캐시 메모리 및 상기 디렉토리 컨트롤러에 결합되는 제어 논리
    를 포함하고,
    상기 제어 논리는,
    상기 캐시 메모리의 복수의 블록 주소로부터 복수의 블록의 제거를 반영하도록 상기 수집 테이블을 갱신;
    상기 수집 테이블에 반영된 상기 복수의 블록의 상기 제거를 특정하도록 구성되는 수집 메시지를 생성; 및
    상기 수집 메시지를 파스하고 상기 수집 메시지에 특정된 상기 캐시 메모리로부터의 상기 제거를 반영하도록 상기 디렉토리 내 복수의 디렉토리 엔트리를 갱신하도록 구성되는 상기 디렉토리 컨트롤러로 상기 수집 메시지를 전송하도록 구성되는,
    멀티코어 칩.
16. 제15항에 있어서,
    상기 캐시 메모리의 상기 복수의 블록 주소로부터 상기 복수의 블록의 제거를 반영하도록 상기 수집 테이블을 갱신하기 위하여, 상기 제어 논리는 상기 캐시 메모리의 상기 복수의 블록 주소로부터 하나 이상의 깨끗한 블록의 제거를 반영하도록 상기 수집 테이블을 갱신하도록 구성되는, 멀티코어 칩.
17. 제16항에 있어서,
    상기 제어 논리는 상기 캐시 메모리의 상기 복수의 블록 주소로부터 하나 이상의 오염된 깨끗하지 않은 블록의 제거를 무시하도록 더 구성되는, 멀티코어 칩.
18. 제15항에 있어서,
    상기 수집 메시지에 특정된 상기 캐시 메모리로부터의 상기 제거를 반영하도록 상기 디렉토리 내 상기 복수의 디렉토리 엔트리를 갱신하기 위하여, 상기 제어 논리는,
    상기 캐시 메모리의 블록 주소로부터 블록의 제거를 검출;
    상기 수집 테이블이 상기 블록 주소에 대응하는 엔트리를 포함하는지 여부를 결정;
    상기 수집 테이블이 상기 블록 주소에 대응하는 상기 엔트리를 포함하지 않는다는 결정에 응답하여, 상기 수집 테이블 내 상기 엔트리를 생성하고 상기 블록 주소로부터 상기 블록의 상기 제거를 반영하도록 상기 엔트리를 갱신; 및
    상기 수집 테이블이 상기 블록 주소에 대응하는 상기 엔트리를 포함한다는 결정에 응답하여, 상기 블록 주소로부터 상기 블록의 상기 제거를 반영하도록 상기 엔트리를 갱신하도록 구성되는, 멀티코어 칩.
19. 제18항에 있어서,
    상기 엔트리는 태그 부분 및 비트맵 부분을 포함하고, 상기 비트맵 부분 내 각각의 비트는 복수의 연속적인 블록 주소 중 하나에 대응하고, 각각의 비트의 제1 비트 값은 상기 복수의 연속적인 블록 주소 내 적용 가능한 블록 주소로부터 블록이 제거되었음을 가리키며, 각각의 비트의 제2 비트 값은 상기 복수의 연속적인 블록 주소 내 적용 가능하지 않은 블록 주소로부터 상기 블록이 제거되지 않았음을 가리키는, 멀티코어 칩.
20. 제19항에 있어서,
    상기 태그 부분은 상기 적용 가능한 블록 주소의 부분을 포함하고, 상기 디렉토리 컨트롤러는 상기 비트맵 부분으로부터의 데이터와 상기 태그 부분의 연결에 의해 상기 적용 가능한 블록 주소를 결정하고 상기 적용 가능한 블록 주소로부터 상기 블록의 제거를 반영하도록 상기 복수의 디렉토리 엔트리 중 하나를 갱신하도록 구성되는, 멀티코어 칩.
21. 제19항에 있어서,
    상기 수집 테이블에 반영된 상기 복수의 블록의 상기 제거를 특정하도록 구성되는 상기 수집 메시지를 생성하기 위하여, 상기 제어 논리는,
    상기 수집 테이블로부터 상기 태그 부분 및 상기 비트맵 부분을 회수; 및
    상기 태그 부분 및 상기 비트맵 부분을 포함하는 상기 수집 메시지를 생성하도록 구성되는, 멀티코어 칩.
22. 제19항에 있어서,
    상기 수집 테이블에 반영된 상기 복수의 블록의 상기 제거를 특정하도록 구성되는 상기 수집 메시지를 생성하기 위하여, 상기 제어 논리는,
    상기 수집 테이블로부터 상기 태그 부분 및 상기 비트맵 부분을 회수;
    상기 태그 부분 및 상기 비트맵 부분을 포함하는 제1 수집 메시지를 생성;
    상기 비트맵 부분을 상기 제1 비트 값을 가지는 상기 비트맵 부분 내 복수의 비트에 대응하는 복수의 포인터 값으로 전환; 및
    상기 태그 부분 및 상기 복수의 포인터 값을 포함하는 제2 수집 메시지를 생성하도록 구성되는, 멀티코어 칩.
23. 제22항에 있어서,
    상기 태그 부분은 상기 적용 가능한 블록 주소의 부분을 포함하고, 상기 디렉토리 컨트롤러는 상기 복수의 포인터 값 중 하나와 상기 태그 부분의 연결에 의해 상기 적용 가능한 블록 주소를 결정하고 상기 적용 가능한 블록 주소로부터 상기 블록의 제거를 반영하도록 상기 복수의 디렉토리 엔트리 중 하나를 갱신하도록 더 구성되는, 멀티코어 칩.
24. 제22항에 있어서,
    상기 디렉토리 컨트롤러로 상기 수집 메시지를 전송하기 위하여, 상기 제어 논리는,
    상기 제1 수집 메시지가 상기 제2 수집 메시지보다 더 작은 데이터 사이즈를 가지는지 여부를 결정;
    상기 제1 수집 메시지가 상기 제2 수집 메시지보다 더 작은 데이터 사이즈를 가진다는 결정에 응답하여, 상기 제1 수집 메시지를 상기 디렉토리로 전송 - 상기 디렉토리 컨트롤러는 상기 제1 수집 메시지를 파스하고 상기 제1 수집 메시지에 특정된 상기 캐시 메모리로부터의 상기 제거를 반영하도록 상기 복수의 디렉토리 엔트리를 갱신하도록 구성됨 - ; 및
    상기 제1 수집 메시지가 상기 제2 수집 메시지보다 더 작은 데이터 사이즈를 가지지 않는다는 결정에 응답하여, 상기 제2 수집 메시지를 상기 디렉토리로 전송 - 상기 디렉토리 컨트롤러는 상기 제2 수집 메시지를 파스하고 상기 제2 수집 메시지에 특정된 상기 캐시 메모리로부터의 상기 제거를 반영하도록 상기 복수의 디렉토리 엔트리를 갱신하도록 구성됨 -
    하도록 구성되는, 멀티코어 칩.
25. 제19항에 있어서,
    상기 제어 논리는,
    상기 비트맵 부분의 현재 입도에 대한 군집 개수를 결정;
    상기 비트맵 부분의 제안된 입도에 대한 군집 개수를 결정; 및
    상기 군집 개수들에 기초하여, 상기 현재 입도 및 상기 제안된 입도를 비교하기 위한 기준이 충족되는지 여부를 결정하도록 구성되는, 멀티코어 칩.
26. 제25항에 있어서,
    상기 비트맵 부분의 상기 현재 입도에 대한 상기 군집 개수를 결정하기 위하여, 상기 제어 논리는 상기 비트맵 부분의 현재 입도 x에 대한 군집 개수 pop(x)를 결정하도록 구성되고,
    상기 비트맵 부분의 상기 제안된 입도에 대한 상기 군집 개수를 결정하기 위하여, 상기 제어 논리는 상기 비트맵 부분의 제안된 입도 y에 대한 군집 개수 pop(y)를 결정하도록 구성되며,
    상기 현재 입도 및 상기 제안된 입도를 비교하기 위한 상기 기준이 충족되는지 여부를 결정하기 위하여, 상기 제어 논리는 부등식

    

    이 충족되는지 여부를 결정 - c는 루트의 사이즈 및 패킷 헤더와 에러 정정/검출 코드를 위해 사용되는 추가적인 비트를 나타내는 상수임 - 하도록 구성되는, 멀티코어 칩.
27. 제26항에 있어서,
    상기 제어 논리는 상기 부등식

    

    이 충족된다는 결정에 응답하여 상기 현재 입도로부터 상기 제안된 입도로 상기 비트맵 부분을 재구성하도록 더 구성되는, 멀티코어 칩.
28. 제26항에 있어서,
    상기 제어 논리는 상기 부등식

    

    이 충족되지 않는다는 결정에 응답하여 상기 비트맵 부분의 상기 현재 입도를 유지하도록 더 구성되는, 멀티코어 칩.
29. 컴퓨터에 의한 실행에 응답하여, 상기 컴퓨터가,
    멀티코어 칩 내 캐시 메모리의 제1 복수의 연속적인 블록 주소로부터 제1 복수의 깨끗한 블록의 제1 제거를 검출;
    상기 캐시 메모리의 제2 복수의 연속적인 블록 주소로부터 제2 복수의 깨끗한 블록의 제2 제거를 검출;
    상기 제1 복수의 깨끗한 블록의 상기 제1 제거를 반영하도록 상기 멀티코어 칩 내 수집 테이블 내 제1 엔트리를 갱신 - 상기 제1 엔트리는 상기 제1 복수의 연속적인 블록 주소에 대응함 - ;
    상기 제2 복수의 깨끗한 블록의 상기 제2 제거를 반영하도록 상기 멀티코어 칩 내 상기 수집 테이블 내 제2 엔트리를 갱신 - 상기 제2 엔트리는 상기 제2 복수의 연속적인 블록 주소에 대응함 - ;
    상기 수집 테이블의 상기 제1 엔트리에 반영된 상기 제1 복수의 깨끗한 블록의 상기 제1 제거를 특정하도록 구성되는 제1 수집 메시지를 생성;
    상기 수집 테이블의 상기 제2 엔트리에 반영된 상기 제2 복수의 깨끗한 블록의 상기 제2 제거를 특정하도록 구성되는 제2 수집 메시지를 생성; 및
    상기 멀티코어 칩 내 디렉토리에 결합되는 디렉토리 컨트롤러로 상기 제1 수집 메시지 및 상기 제2 수집 메시지를 전송 - 상기 디렉토리 컨트롤러는 상기 제1 수집 메시지 및 상기 제2 수집 메시지를 파스, 상기 제1 수집 메시지에 특정된 상기 캐시 메모리로부터의 상기 제1 제거를 반영하도록 상기 디렉토리 내 제1 복수의 디렉토리 엔트리를 갱신, 및 상기 제2 수집 메시지에 특정된 상기 캐시 메모리로부터의 상기 제2 제거를 반영하도록 상기 디렉토리 내 제2 복수의 디렉토리 엔트리를 갱신하도록 구성됨 -
    하도록 하는 컴퓨터 실행 가능 명령어가 저장된 일시적이지 않은 컴퓨터 판독 가능 매체.
30. 제29항에 있어서,
    상기 제1 엔트리는 태그 부분 및 비트맵 부분을 포함하고, 상기 비트맵 부분 내 각각의 비트는 상기 제1 복수의 연속적인 블록 주소 중 하나에 대응하고, 각각의 비트의 제1 비트 값은 상기 제1 복수의 연속적인 블록 주소 내 적용 가능한 블록 주소로부터 깨끗한 블록이 제거되었음을 가리키며, 각각의 비트의 제2 비트 값은 상기 제1 복수의 연속적인 블록 주소 내 적용 가능하지 않은 블록 주소로부터 상기 깨끗한 블록이 제거되지 않았음을 가리키는, 일시적이지 않은 컴퓨터 판독 가능 매체.
31. 제30항에 있어서,
    상기 태그 부분은 상기 적용 가능한 블록 주소의 부분을 포함하고, 상기 디렉토리 컨트롤러는 상기 비트맵 부분으로부터의 데이터와 상기 태그 부분의 연결에 의해 상기 적용 가능한 블록 주소를 결정하고 상기 적용 가능한 블록 주소로부터 상기 깨끗한 블록의 제거를 반영하도록 상기 제1 복수의 디렉토리 엔트리 중 하나를 갱신하도록 더 구성되는, 일시적이지 않은 컴퓨터 판독 가능 매체.
32. 캐시 제거를 처리(handle)하기 위한 컴퓨터 구현 방법으로서,
    컴퓨팅 장치에 의하여, 블록이 캐시 메모리로부터 제거될 것이라고 결정하는 단계;
    상기 컴퓨팅 장치에 의하여, 상기 블록이 오염된 블록인지 여부를 결정하는 단계;
    상기 블록이 오염된 블록이라는 결정에 응답하여, 상기 컴퓨팅 장치에 의하여, 오염된 블록으로서의 상기 블록의 제거를 캐시 일관성 디렉토리(cache coherence directory)에 통지하는 단계;
    상기 블록이 오염된 블록이 아니라는 결정에 응답하여, 상기 컴퓨팅 장치에 의하여, 수집 테이블이 상기 블록의 블록 주소에 대응하는 엔트리를 포함하는지 여부를 결정하는 단계;
    상기 수집 테이블이 상기 블록의 상기 블록 주소에 대응하는 엔트리를 포함하지 않는다는 결정에 응답하여, 상기 컴퓨팅 장치에 의하여, 상기 블록의 상기 블록 주소에 대응하는 상기 수집 테이블 내 엔트리를 생성하고 깨끗한 블록으로서의 상기 캐시 메모리로부터의 상기 블록의 제거를 반영하도록 상기 엔트리를 갱신하는 단계; 및
    상기 수집 테이블이 상기 블록의 상기 블록 주소에 대응하는 상기 엔트리를 포함한다는 결정에 응답하여, 상기 컴퓨팅 장치에 의하여, 상기 깨끗한 블록으로서의 상기 캐시 메모리로부터의 상기 블록의 상기 제거를 반영하도록 상기 엔트리를 갱신하는 단계
    를 포함하는 컴퓨터 구현 방법.
33. 제32항에 있어서,
    상기 컴퓨팅 장치에 의하여, 상기 캐시 메모리로부터 복수의 블록의 복수의 제거를 특정하도록 구성되는 수집 메시지를 생성하는 단계 - 상기 복수의 제거는 상기 블록의 상기 제거를 포함함 - ; 및
    상기 수집 메시지를 상기 캐시 일관성 디렉토리로 전송하는 단계
    를 더 포함하고,
    상기 캐시 일관성 디렉토리는 상기 수집 메시지를 파스하고 상기 수집 메시지에 특정된 상기 캐시 메모리로부터의 상기 복수의 제거를 반영하도록 복수의 디렉토리 엔트리를 갱신하도록 구성되는, 컴퓨터 구현 방법.

Images