KR101188472B1 - 데이터 즉시 청킹을 사용하여 파일 입출력을 스케줄 하는 방법 - Google Patents

데이터 즉시 청킹을 사용하여 파일 입출력을 스케줄 하는 방법 Download PDF

Info

Publication number
KR101188472B1
KR101188472B1 KR1020107026222A KR20107026222A KR101188472B1 KR 101188472 B1 KR101188472 B1 KR 101188472B1 KR 1020107026222 A KR1020107026222 A KR 1020107026222A KR 20107026222 A KR20107026222 A KR 20107026222A KR 101188472 B1 KR101188472 B1 KR 101188472B1
Authority
KR
South Korea
Prior art keywords
instructions
request
layers
processing
tree structure
Prior art date
Application number
KR1020107026222A
Other languages
English (en)
Other versions
KR20110074489A (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 소니 컴퓨터 엔터테인먼트 아메리카 엘엘씨
Publication of KR20110074489A publication Critical patent/KR20110074489A/ko
Application granted granted Critical
Publication of KR101188472B1 publication Critical patent/KR101188472B1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements 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/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5038—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the execution order of a plurality of tasks, e.g. taking priority or time dependency constraints into consideration
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/506—Constraint

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

인커밍 I/O 요청은 프로세서에서 실행되는 어플리케이션으로부터 수신된다. 프로세서 실행가능한 인스트럭션들을 포함하는 트리 구조는 처리 과정의, I/O 요청과 연관된 하나 이상의 계층들을 정의한다. 인스트럭션들은 처리 과정의 하나 이상의 계층들 각각에서 I/O 요청에 있는 데이터를 하나 이상의 청크들로 나눈다. 각각의 인스트럭션은 이전 계층에 있는 하나 이상의 대응하는 인스트럭션들에 연관된 데이터 종속성을 가진다. 인스트럭션들은 청크들 각각의 위치 및 처리 과정의 다른 계층들의 청크들 사이 데이터 종속성들을 판단함으로써, 처리 순서로 분류된다. 하나 이상의 인스트럭션들은 처리 순서에 적어도 부분적으로 의존하는 스케줄에 삽입된다. 처리 순서에 따라, I/O 요청은 프로세서에 의해 스케줄에 따라 인스트럭션들을 실행함으로써, 수행된다.

Description

데이터 즉시 청킹을 사용하여 파일 입출력을 스케줄 하는 방법 {File input/output scheduling using immediate data chuncking}
본 발명의 실시예들은 컴퓨터 게임 및 그와 관련된 어플리케이션들에 관한 발명이며, 특히 컴퓨터 게임 및 그와 관련된 어플리케이션들에 있어서 파일 입출력(input/output; I/O)을 관리하는 방법에 관한 발명이다.
본 출원은 2009년 10월 26일에 출원되고, 엔드루 알. 떼일러 (Andrew R. Thaler)가 발명자 이고, 데이터 즉시 청킹을 사용하여 파일 입출력을 스케줄하는 방법 (File input/output scheduling using immediate data chunking)의 제목을 가진 미국 특허 가출원 61/255,013을 기초로 우선권 주장을 하는 출원이다. 이 우선권 주장 기초 출원의 기재 내용 전부는 본 명세서에 참조로서 기재되어 있는 것으로 한다.
또한 본 출원은 2010년 10월 12일에 출원되고, 엔드루 알. 떼일러 (Andrew R. Thaler)가 발명자 이고, 데이터 즉시 청킹을 사용하여 파일 입출력을 스케줄하는 방법(File input/output scheduling using immediate data chunking)의 제목을 가진 미국 특허 출원 12/902,768을 기초로 우선권 주장을 하는 출원이다. 이 우선권 주장 기초 출원의 기재 내용 전부는 본 명세서에 참조로서 기재되어 있는 것으로 한다.
비디오 게임과 같은 많은 소프트웨어 어플리케이션들은, 어플리케이션 내 미디어 장치로의 접근이 더 효율적이도록 또한 그 신뢰도(reliability)를 높이기 위한 파일 입출력(I/O) 스케줄러를 구비한다. 파일 I/O 시스템(FIOS)은 스케줄러 및 선택적 I/O 필터 계층들을 구비하는 여러 부분으로 구성된 파일들을 접속하기 위한 미들웨어 계층(middleware layer)이다. 스케줄러는 I/O 요청들이 임의의 기한(deadline)과 우선순위(priority)의 제약(constraint)을 조건으로 가능한한 최단 시간내에 완료되도록 I/O 요청들을 최적화 분류하도록 디자인되어 있다. 필터 계층들은 복원(decompression)이나 캐싱(caching)과 같은 추가적 서비스를 제공할 수 있다.
다른 다수의 게임 구성요소들은 미디어 저장부에 있는 파일들에 대하여 입출력 접속을 요구한다. 오디오 구성요소는 오디오 파일을 로딩하고, 게임 실행 엔진은 레벨 정의 정보를 로딩하고, 그래픽 구성요소는 텍스처 지도 및 모델들을 로딩하고, 영화 구성요소는 오디오 비주얼 파일을 로딩하고 서브시스템은 대용량 WAD 파일을 로딩한다. 이러한 저장부는 광 디스크(유니버설 미디어 디스크(universal media disc, UMD), 콤팩트 디스크(CD), 디지털 비디오 디스크(DVD), 블루 레이 디스크(Blue-Ray disc) 등)와 같은 게임 전달 매체, 하드 디스크와 같은 중간 저장 매체나 플렛폼(platform)이 발달함에 따라 사용되는 다른 종류의 매체가 될 수 있다.
비디오 게임과 같은 단일의 어플리케이션은 일반적으로 다수의 구성요소들을 가진다. 이러한 구성요소들은 각각의 I/O 요구 사항들(requirements)을 가진다. 어떤 구성요소들은 스트리밍 방식으로 미디어 장치에 접속되도록 요구한다. 이러한 스트리밍 방식에서 I/O 시스템은 구성요소가 잇따라 스트리밍 된 데이터를 게임 플레이어로 전송할 수 있도록 파일에 저장된 데이터를 구성요소에게 스트리밍 한다. 예를 들면, 오디오 구성요소는 일반적으로 사운드 트랙을 재생하기 위해 오디오 파일을 스트리밍 하고, 영화 구성요소는 플레이어 기기가 영화를 재생하도록 오디오 비디오 콘텐츠를 스트리밍 한다. 다른 구성요소들은 비스트리밍(non-streaming) 방식의 접속만을 필요로 한다. 이러한 방식에서는 단위화된 데이터(이하 청크(chunk))들이 구성요소에 의해 처리되기 위해 파일에서 검출(retrieve)된다. 이와 같은 구성요소들은 데이터를 처리하기 위해 데이터의 연속적인 흐름을 필요로 하지 않지만, 청크들의 전달 시점은 종종 중요하다. 어플리케이션이 데이터를 필요로 할 때 데이터를 수신하지 못 하면 성능이 저하될 수 있다.
현재 청킹 과정은 I/O 요청을 실행하는 동안 수행된다(즉, I/O 요청에 의해 데이터를 단위화하거나 청크들로 나눈다). 청크들 사이의 데이터 종속성(dependency)은 실행 과정 전에 결정되지 않는다. 이에 I/O 요청들이 비효율적으로 처리된다. 예를 들면 특정 I/O 요청은 전송되기 전에 복호 및 복원되야 하는 데이터를 요청할 수 있다. I/O 시스템은 복원 전에 특정 청크가 복호화되는 것을 필요로 할 수 있다. 그러나 복호되는 청크 크기와 복원되는 청크 크기가 상이할 수 있다. 예를 들면 복호화 과정과 연관된 청크 크기는 64 킬로바이트와 같이 고정된 값을 가질 수 있지만, 반면에 복원화 과정과 연관된 청크의 크기는 다양한 값을 가질 수 있다. 따라서 복호화되는 청크들과 복원화되는 청크들 사이의 데이터 종속성을 판단하지 않고서는 필요한 복호화된 청크들이 처리되고 나서 특정 청크의 복원화 과정을 개시하는 대신, 특정 청크가 복원되기 전에 파일 전체가 복호화 되어야 한다.
이와 유사하게 다수의 미디어 소스(source)들로부터 추출 될 데이터를 요구하는 특정 I/O 요청이 현재 실행되는 동안 청크로 나누어지는 방식으로는 비효율적으로 처리될 수 있다. 실행되기 전에 청크들 사이의 데이터 종속성을 판단하지 않고서는, 다른 미디어 장치로부터의 데이터가 처리되는 동안 이론적으로 두 개의 미디어 장치들로부터의 데이터가 동시에 처리될 수 있을 때, 미디어 장치는 대기 상태에 있을 수 있다. 이는 결과적으로 비디오 게임이나 다른 어플리케이션의 기능이 느려지게 한다.
이에 더하여 비디오 게임은 주로 상당량의 입출력 과정을 수행한다. 게임 이벤트들을 대부분 기한을 맞춰야하는 시간 기반의 이벤트들이다. 예를 들어 게임 사용자가 A 지점에서 B 지점으로 이동하는 경우, 게임 사용자가 B 지점에 도착하기 전에 B 지점과 연관된 데이터들을 위한 파일들을 게임 프로그램이 획득해야한다. 게임 구성요소들은 미디어에서 데이터를 추출하는 저수준(low level)의 I/O 프리미티브(primitive)를 사용할 수 있지만, 이러한 프리미티브들은 다수의 구성요소들이 동시에 같은 장치로부터 데이터를 요구할 때 장치의 경합(contention)을 소화하지 못한다. 재밍된(jammed) I/O 요청들은 데이터 스트리밍의 흐름을 방해하거나 필요할 때 중요한 데이터 청크들이 구성요소로 전송되지 못하게 할 수 있다.
일반적으로 어플리케이션의 구성요소들이 서로의 I/O 활동들에 대하여 인식하고 있지 않기 때문에, 구성요소들의 I/O 요청들은 종종 상당량의 (데이터를 검색하기 위해 왔다갔다하는)과다 탐색으로 고도의 비효율적 I/O 패턴을 초래한다. 게임 용량이 커지면서 과다 탐색과 비효율적 데이터 추출 과정이 늘어나는 추세에 있다.
이와 같은 배경으로부터 본 발명의 실시예들이 안출되었다.
본 발명의 설명은 하기 상세한 설명과 첨부된 도면들을 참조해서 고려함으로 빠르게 이해될 수 있다. 첨부된 도면들 중:
도 1은 본 발명의 실시예에 따른 파일 I/O 시스템(FIOS)을 구현하는 시스템의 블록도이고,
도 2는 본 발명의 다른 실시예에 따른 FIOS를 구현하는 다른 시스템의 블록도이고,
도 3은 본 발명의 실시예에 따른 FIOS 소프트웨어의 블록도이고,
도 4는 본 발명의 실시예에 따른 FIOS에서의 과정들을 도시하는 흐름도 이며,
도 5는 본 발명의 실시예에 따른 FIOS에서 사용되는 소프트웨어 스케줄러의 일례를 도시하는 흐름도이다.
하기 상세한 설명은 도시적 목적으로 특정 요소들을 포함하고 있지만 당업자라면 하기 설명의 많은 변경물과 변형물들이 본 발명의 범위 내에서 존재할 수 있음을 인지할 것이다. 이에 따라 하술된 본 발명의 실시예들은 어떠한 일반성을 잃지 않고, 청구된 발명을 한정시키지 않으며 개진된다.
본 발명의 실시예들은 파일 입출력 시스템(file I/O system; FIOS) 주변에서 구현될 수 있다. 이러한 FIOS는 시스템의 모든 I/O가 통과하는 중앙집중된 계층을 제공한다. FIOS는 각각의 I/O 요청을 최적으로 처리하기 위한 트리 구조(tree structure)를 생성하는 인스트럭션들을 포함할 수 있다. 또한 FIOS는 I/O 요청들을 스케줄 하고, 가장 효율적으로 I/O 요청들을 서비스하는 순서를 판단하는 인스트럭션들을 포함할 수 있다.
예를 들어 컴퓨터로 구현되는 시스템(100)은 도 1에 도시된 바와 같이 본 발명의 실시에에 따라 FIOS를 구현하도록 설정될 수 있다. 일례로 일반성을 잃지 않고, 시스템(100)은 개인 컴퓨터, 비디오 게임 콘솔(console) 핸드 핼드 게임 기기, 핸드폰, 개인 휴대 정보 단말기(personal digital assistant) 또는 본 발명의 실시예를 실행하기 적합한 다른 디지털 기기로 구현될 수 있다. 시스템(100)은 프로세서 부(105)와 프로세서 부(105)에 연결된 메인 메모리(106)를 포함할 수 있다. CPU(105)는 소프트웨어 어플리케이션과 선택적으로 운용 시스템을 실행하도록 설정될 수 있다. 본 발명의 어떤 실시예들은 특정 종류의 프로세서 구조를 이용할 수 있다. 이러한 프로세서 구조의 CPU(105)는 메인 프로세서(105A)와 보조 프로세서(105B)와 보조 프로세서(105B) 전용의, 연관된 로컬 메모리(106B)를 포함한다. 이러한 프로세서 구조의 일례로는 셀 프로세서가 될 수 있다. 셀 프로세서 구조의 예는 인터네셔널 비즈니스 머신즈 코포레이션(International business Machines Corporation), 소니 컴퓨터 엔터테인먼트 인코포레이티드(Sony Computer Entertainment Incorporated), 및 도시바 코포레이션(Toshiba Corporation)이 저작권을 소지한 2005년 8월 8일에 출판된 셀 광대역 엔진 구조(Cell Broadband Engine Architecture)에 상세하게 설명된다. 상기 문서 전체 내용이 본 명세서에 참조로 인용되었으며, http://cell.scei.co.jp/ 웹 사이트에서 다운로드할 수 있다.
메인 메모리(106)는 CPU(105)에 의해 사용되기 위한 어플리케이션들과 데이터를 저장할 수 있다. 메인 메모리(106)는 RAM, DRAM, ROM, 등과 같은 집적 회로의 형태일 수 있다. 컴퓨터 프로그램(101)은 프로세서(105)에서 실행될 수 있는 인스트럭션의 모양으로 메모리(106)에 저장될 수 있다. 프로그램(101)의 인스트럭션들은 이로 한정되지는 않지만 하술되는 특정 특징을 가진 FIOS를 구현하도록 설정될 수 있다. 메모리(106)는 예를 들어 인커밍 I/O 요청, 스케줄된 I/O 요청, 발행된 I/O 요청, 완료된 I/O 요청 및 프리 I/O 요청을 위한 스택(stack)이나 큐(queue)의 형태의 I/O 큐들(101Q)을 포함할 수 있다. 이러한 큐들의 예는 하기에서 설명된다.
예를 들어 FIOS 프로그램(101)은 하기와 같은 인스트럭션들을 포함할 수 있다.
a) 미디어 장치(118)와 관련된 인커밍 I/O 요청을 어플리케이tus(103)으로부터 수신하는 인스트럭션.
b) 위치 및 전송될 데이터의 청크들(즉 단위화된 데이터들)의 데이터 종속성을 판단하여 I/O 요청을 처리하는 최적의 순서를 형성하도록 구성된 트리 구조를 생성하는 인스트럭션.
c) 메모리(106)에 내장된 스케줄에 인커밍 I/O 요청을 삽입하는 인스트럭션. 이 때 스케줄에서의 인커밍 I/O 요청의 위치는 적어도 트리 구조의 처리 순서에 부분적으로 의존한다.
d) 스케줄과 트리 구조에 따라 I/O 요청을 구현하는 인스트럭션.
또한 클라이언트 시스템(100)은 I/O 구성요소(111), 전원 공급자(power supplies; P/S)(112), 클럭(clock; CLK)(113) 및 캐시(cache)(114)와 같이 공지된 지원 기능부들을 포함할 수 있다. 클라이언트 장치(100)는 하드 디스크 드라이브와 같은, 어플리케이션들 및 데이터의 비휘발성 저장소를 제공하는 급속 기억 장치(fast storage device)(115)를 더 포함할 수 있다. 급속 기억 장치(115)는 이에 한정되는 것은 아니지만, 비교적 느린 미디어 장치(118)에서 추출된 파일들(116)의 임시 또는 장기 저장소로 사용될 수 있다. 급속 기억 장치(115) 상의 파일(116)은 비교적 느린 미디어 장치(118)가 아닌 다른 소스들로부터 추가적으로 전달될 수 있다. 예를 들어 파일들(116)은 이로 제한되지는 않지만, 운용 시스템 파일, 어플리케이션에 의해 생성된 임시 파일, 사진/오디오/비디오와 같은 사용자 데이터, 다운로드된 콘텐츠 등을 포함할 수 있다. 일례로 저장부(115)는 고정형(fixed) 디스크 드라이브, 탈착형(removable) 디스크 드라이브, 플래쉬 메모리 장치 또는 테이프 드라이브가 될 수 있다. 비교적 느린 미디어 장치(118)는 고용량 광 디스크 드라이브, 예를 들어 CD-ROM 드라이브, DVD-ROM 드라이브, HD-DVD 드라이브, 블루 레이(Blu-Ray) 디스크 드라이브, UMD 드라이브, 또는 다른 광 저장 장치들이 될 수 있다. 미디어 장치(118)로부터 프리페치된(pre-fetched) 파일들(116)은 메모리(106)로 신속히 로딩되기 위해 저장부(115)의 하드웨어 캐시에 임시로 저장될 수 있다.
하나 이상의 사용자 입력 장치들(120)은 하나 이상의 사용자들로부터의 사용자 입력들을 시스템(100)으로 통신하는데 사용될 수 있다. 예를 들어 하나 이상의 사용자 입력 장치들(120)은 I/O 장치들을 통해 클라이언트 장치(100)에 연결될 수 있다. 적합한 입력 장치들(120)의 예로는 키보드, 마우스, 조이스틱, 터치 패드, 터치 스크린, 광 펜, 스틸(still) 또는 비디오 카메라 그리고/또는 마이크가 될 수 있다. 클라이언트 장치(100)은 전자 통신 네트워크(127)를 통한 통신을 용이하게 하는 네트워크 인터페이스(125)를 포함할 수 있다. 네트워크 인터페이스(125)는 근거리 통신망과 인터넷과 같은 광역통신망을 통한 무선 또는 유선 통신을 구현하도록 설정될 수 있다. 시스템(100)은 네트워크(127)를 사용하여 하나 이상의 메시지 패킷들(126)을 통해 데이터 그리고/또는 네트워크(127)를 사용하여 하나 이상의 메시지 패킷들(126)을 송수신할 수 있다.
시스템(100)은 그래픽 처리부(GPU)(135)와 그래픽 메모리(140)를 구비할 수 있는 그래픽 서브시스템(130)을 더 포함할 수 있다. 그래픽 메모리(140)는 출력 이미지의 픽셀 각각을 위한 픽셀 데이터를 저장하는데 사용되는 표시부 메모리(예. 프레임 버퍼(frame buffer))를 포함할 수 있다.
그래픽 메모리(140)는 GPU(135)와 같은 장치에 통합되거나, GPU(435)와 분리된 장치로 연결되거나, 그리고/또는 메모리(106)에 저장될 수 있다. 픽셀 데이터는 CPU(105)로부터 직접 그래픽 메모리(140)에 제공될 수 있다. 선택적으로 CPU(105)는 GPU(135)에게 요구된 출력 이미지들을 규정하는 데이터 및/또는 인스트럭션들을 제공할 수 있다. GPU(135)는 상기 데이터 및/또는 인스트럭션들로부터 하나 이상의 출력 이미지들의 픽셀 데이터를 생성할 수 있다. 요구된 출력 이미지들을 규정하는 데이터 및/또는 인스트럭션들은 메모리(106) 및/또는 그래픽 메모리(140)에 저장될 수 있다. 한 실시예에 있어서, GPU(135)는 장면에 대한 기하학적 배열(geometry), 조명, 음영, 질감, 움직임, 및/또는 카메라 파라미터들을 정하는 인스트럭션들 및 데이터로부터 출력 이미지의 픽셀 데이터를 생성하기 위한 3 차원 렌더링(rendering) 능력을 구비하게 설정될 수 있다. GPU(135)는 쉐이더(shader) 프로그램을 실행할 수 있는 프로그램 가능한 하나 이상의 실행부들을 포함할 수 있다.
그래픽 서브시스템(130)은 비디오 표시부(150)에 표시되도록, 그래픽 메모리(140)로부터의 이미지에 대한 픽셀 데이터를 주기적으로 출력할 수 있다. 비디오 표시부(150)는 CRT, LCD, 플레즈마, OLED 표시부들을 포함하는 시스템(100)에서의 신호에 응하여 비쥬얼(visual) 정보를 표시할 수 있는 어떠한 장치도 될 수 있다. 컴퓨터 시스템(100)은 아날로그나 디지털 형태의 신호를 표시부(150)에 제공할 수 있다. 예를 들면, 표시부(150)는 텍스트, 숫자, 그래픽 기호 또는 이미지를 표시하는 브라운관(cathode ray tube; CRT)이나 플랫 패널 스크린을 포함할 수 있다. 또한 표시부(150)는 가청적(audible)이거나 아니면 감지 가능한 음향을 생성하는 하나 이상의 오디오 스피커를 포함할 수 있다. 이러한 음향을 용이하게 생성하기 위해 시스템(100)은 프로세서(105), 메모리(106), 및/또는 저장부(115)에서 제공된 인스트럭션 및/또는 데이터로부터 아날로그나 디지털 형태의 오디오 출력 신호를 생성하도록 구성된 오디오 프로세서(155)를 더 포함할 수 있다.
CPU(105), 메모리(106), 지원 기능부들(110), 데이터 저장소(115), 미디어 장치(118), 사용자 입력 장치들(120), 네트워크 인터페이스(125) 및 오디오 프로세서(155)를 포함하는, 시스템(100)의 구성요소들은 하나 이상의 데이터 버스(160)를 통하여 서로에게 동작 가능하게 접속(operably connected)되어 있을 수 있다. 이러한 구성요소들은 하드웨어, 소프트웨어 또는 펌웨어나 상술된 구성요소들 두 개 이상의 조합으로 구현될 수 있다.
본 발명의 어떤 실시예는 셀 프로세서 구조나 이와 유사한 프로세서 구조를 이용할 수 있다. 도 2는 본 발명의 실시예에 따른 FIOS를 구현하도록 구성된 셀 프로세서(200)을 도시한다. 셀 프로세서(200)는 메인 메모리(202), 단일의 파워 프로세서 엘리먼트(power processor element; PPE)(204) 및 여덟 개의 시너지스틱 프로세서 엘리먼트(synergistic processor element; SPE)(204)를 포함한다. 예를 들면 PPE(204)는 64 비트 파워 피씨 프로세서부(Power PC Processor Unit; PPU)와 그와 연동된 캐시들을 포함할 수 있다. 예를 들어 CBEA 기반 시스템(CBEA-compliant system)들은 PPE(204) 내에 벡터 멀티미디어 확장부(vector multimedia extension unit)를 구비할 수 있다. PPE(204)는 시스템 관리 리소스(resource)(예. 메모리 보호 표(memory protection table))를 접속할 수 있는, 일반적인 처리부가 될 수 있다. 하드웨어 리소스들은 PPE(204)에 의해 보여지는 실제 어드레스(address) 공간에 명시적으로 매핑될 수 있다. 따라서 PPE(204)는 이러한 리소스들 중 어느 하나를 적당한, 유효한 주소 값을 사용하여 직접적으로 어드레스를 지정할 수 있다. PPE(204)의 주된 기능은 서로 다른 SPE들(206)을 위해 태스크(task)를 관리하고 분배하는 것이다. PPU는 FIOS 프로그램(101)의 코딩된 인스트럭션들을 실행할 수 있다.
SPE(206)는 PPE(204)보다는 SPE(206)가 어떠한 시스템 관리 기능들을 수행할 필요가 없다는 면에서, 덜 복잡한 연산부이다. SPE(206) 각각은 종종 시너지스틱 프로세서부(SPU)로 불리는 프로세서부와 그와 연견된 로컬 저장부(local store; LS)를 포함한다. SPE(206)는 일반적으로 단일의 인스트럭션과 다수의 데이터(single instruction, multiple data; SIMD) 능력을 가지며 주로 데이터를 처리하고 분배된 태스크(task)들을 수행하기 위해 어떠한 필요한 (PPE(204)에 의해 설정된 접속 특성들을 대상으로 하는)데이터 전송을 개시한다. SPE(206)는 FIOS 프로그램(101)의 일부를 구현하는 인스트럭션들(207)을 로컬 저장부에 저장할 수 있다. SPE(206)의 용도는 더 높은 연산부 밀도를 요구하고 제공된 인스트럭션 세트를 효율적으로 사용할 수 있는어플리케이션을 가능하게 하는데에 있다. 여덟 개의 SPE들이 일례로 도시되었지만, 셀 프로세서(200)는 어떠한 수의 SPE들로도 설정될 수 있다. 도 2를 참조하면, 메모리(202), PPE(204) 및 SPE(206)은 서로 통신할 수 있으며 링 종류(ring-type)의 엘리먼트 연결 버스(element interconnect bus)(210)를 통해 I/O 장치(208)와도 통신할 수 있다. 메모리(202)는 메모리 인터페이스 컨트롤러(memory interface controller; MIC)를 통해PPE(204)와 SPE들(206)에 의해, 접속될 수 있다.
메모리(202)는 예를 들어, 하술된 인커밍, 스케줄, 발행, 완료, 프로 및 프리페치(pre-fetch)된 큐들과 같은 I/O 큐들(203)을 내포할 수 있다. 메모리(202)는 또한, 본 명세서에 서술된 FIOS 프로그램(101)과 동일한 특징들을 가진 FIOS 프로그램(101)의 일부를 내포할 수 있다. PPE(204)는 내부 캐시(L1)과 외부 캐시(L2)를 포함할 수 있다. PPE는 내부 캐시(L1)에 FIOS 프로그램(101)의 일부를 저장할 수 있다. FIOS 프로그램(101)과 SPE 구현 가능한 파일 전송 인스트럭션들(207)이나 이들의 일부 또한 메모리(202)에 저장될 수 있어서, SPE(206)와 PPE(204)가 필요로 할 때 접속될 수 있다.
예를 들면 도 3에 도시된 바와 같이 FIOS 프로그램(101)은 저장부(115)와 같은 하드웨어나 미디어 장치(118)와 인터페이스 하는 과정을 용이하게 하는 미디어 스택(media stack)(300)을 포함할 수 있다. 미디어 스택(300)은 트리 구조 계층(301), 스케줄러(303), 하나 이상의 미디어 필터 계층(305), 장치 미디어 계층 (307), 프로세서 파일 시스템(file system; FS) 판독 계층(309) 및 하드웨어 계층(311)을 포함할 수 있다.
트리 구조 계층(301)은 전송될 I/O 요청 각각과 관련된 데이터를 최적으로, 용이하게 처리하도록 맵(map)을 생성한다. 우선 주어진 I/O 요청과 연관된 (예. 복호화, 복원화, 디아카이빙(de-archiving) 등) 하나 이상의 처리 계층(306)을 지정하는 트리 구조(313)가 생성된다. I/O 요청 당 전송되거나 수신될 데이터는 트리 구조(313)의 계층(306)들 각각에서 처리되고 트리 구조(313)는 이전 계층의 충분한 데이터가 처리될 때까지 그 다음 계층의 처리 과정이 시작되지 않도록 설정된다. 그런 다음 트리 구조(313)는 하나 이상의 처리 계층(306) 각각에서 전송되거나 수신될 데이터를 하나 이상의 청크(chunk)(302)로 나눈다. 특정 처리 계층(306)과 연관된 청크들(302)은 그 특정 처리 계층(306)에 대응하는 하나 이상의 크기들을 가진다. 계층들에 대한 청크 크기는 다를 수 있다. 트리 구조(313)는 청크(302) 각각의 위치와 다른 처리 계층들(306)의 청크들(302) 사이의 데이터 종속성(304)을 판단하여, 다른 계층들의 청크들을 처리하는 최적의 순서를 형성한다.
예를 들어 이로 한정되지는 않지만, I/O 요청은 복호화되고 압축된 데이터를 수신하는 것이 될 수 있다. 우선 트리 구조는 I/O 요청을 수행하기 위해 복호화 계층과 복원화 계층을 포함하는 두 개의 처리 계층들을 생성한다. 이러한 예에 있어서, 전송될 데이터는 어플리케이션에 의해 수신될 수 있기 전에 복원되어야하고, 복원될 수 있기 전에는 복호화되어야 한다. 트리 구조 계층(301)은 처리 계층에 따라 전송될 데이터를 청크들(즉 단위화된 데이터들)로 나눈다. 특히 트리 구조(301)는 데이터를 선택된 크기의 청크들로 나눈다. 그리하여 트리 구조(301)는 다음 레벨의 처리 과정이 시작하기 전에, 데이터 전체를 처리하는 현재 레벨의 처리 과정이 마치지 전까지 기다릴 필요 없이, 단위화된 데이터들이 동시에 처리될 수 있도록 한다. 주어진 청크에 대한 각각의 인스트럭션들은 경로 이름(pathname), 오프셋(offset) 및 길이로 청크를 규정할 수 있다.
예를 들면 복호화 과정은 64K로 고정된 청크 크기에서 완성될 수 있어서, 트리 구조 계층(301)이 복호화 과정을 위해 데이터를 64K 크기의 청크들로 나눌 수 있다. 한편 복원화 과정은 다양한 크기의 청크들을 처리할수 있어서, 트리 구조 계층은 복원화 과정을 위하여 데이터를 여러 크기의 청크들로 나눌 수 있다.
복원화 과정은 다양한 크기로 압축되고, 복호화 된 청크를 받아들이고 고정된 크기의, 압축되지 않은 청크로 복원한다. 트리 구조 계층(301)이나 미디어 필터 계층들(305)은 어떠한 압축되고 복호화된 데이터의 다양한 크기의 청크들이 먼저 복원화되지 않고도, 고정된 크기의 청크들로 복원되는지 결정하도록 구성될 수 있다. 청크들로 나누는 과정이 수행될 때 부호화된 청크의 다양한 길이를 판단하는 과정을 용이하게 하기 위해, 미디어 필터 계층들(305)은 주어진 청크의 크기와 위치를 연산하는데 그들에게 필요한 어떠한 정보이든 RAM에 저장할 수 있다. 예를 들면 FIOS psarc 파일에 대하여 디아카이버(de-archiver) 계층은 psarc 파일의 목차(table of contents; TOC)를 RAM 안에 보유할 수 있다. TOC는 파일 내의 모든 압축된 블록의 크기를 나열하는 표를 포함할 수 있다. 그리고 디아카이버 미디어 계층은 이러한 표로부터 블록의 위치를 유추해낼 수 있다. 그러므로 디아카이버는 압축되지 않은 데이터 블록의 인커밍 요청을 대응하는 압축된 데이터 블록의 요청으로 효율적으로 번역할 수 있다. 이러한 변형 과정을 수행하기 위해 디아카이버가 필요로 하는 유일한 정보는 RAM에 있는 TOC이다. 디아카이버는 트리 노드(tree node)를 생성하기 위해 어떠한 데이터도 실질적으로 판독하거나 복원할 필요가 없다.
복호화 계층이 청크 크기들과 복원화 계층의 청크 크기들이 라인업(line up) 되지 않기 때문에, 주어진 복호화된 청크가 항상 곧바로 복원화 될 수 없다. 대신에, 복원화 계층의 하나의 청크가 복원화 되기 전에 하나 이상의 복원화 계층 청크들이 복호화 되도록 요구될 수 있다. 그러므로 최적의 처리 과정 순서는 각 계층과 연관된 청크들의 위치와 다른 계층들에 있는 청크들 사이의 데이터 종속성을 판단함으로써 수립될 수 있다. 이에 따라 어떠한 계층의 처리 과정이 시작되기 전에 이전 계층 전체를 처리하는 과정이 완료될 때까지 기다릴 필요 없이 이전 계층에 있는 필수 데이터 청크들이 처리되자마자 시작될 수 있다(예. 필수 복호화 레벨 청크들이 복호화되는 과정을 마치면, 특정 청크의 복원화 과정이 시작될 수 있다).
I/O 요청은 가끔씩 하나 이상의 미디어 또는 저장 장치로부터 데이터가 추출되도록 요구할 수 있다. 이에 I/O 요청을 실행하기 전에 데이터 종속성을 판단함으로써 다수의 미디어 또는 저장 장치들로부터의 데이터와 연관된 I/O 요청을 처리하는 과정은 다른 미디어나 저장 장치가 I/O 요청의 해당 부분을 처리하는 동안 하나의 미디어나 저장 장치가 대기하고 있을 필요 없이, 동시에 진행될 수 있다. 예를 들면 이로 한정되지는 않지만, 특정 I/O 요청은 하드 디스크(HD)와 블루-레이 미디어 장치로부터 데이터가 추출하도록 요구할 수 있다. 상기 특정 I/O 요청에 대한 데이터 종속성들을 개설(槪說)(outlining)함으로써, HD로부터 정확히 무엇이 필요하고 블루 레이로부터는 정확히 무엇이 필요한지 판단될 수 있다. 따라서 트리 구조에 따라 처리 과정의 순서가 되었을 때, 한 장치로부터의 데이터가 처리되고 있는 동안 다른 장치가 대기하고 있지 않아도, 두 개의 장치들로부터의 데이터가 동시에 처리될 수 있다.
트리 구조(313)가 생성된 후, 스케줄러(303)는 인커밍 I/O 요청을 구성하는 트리 구조의 인스트럭션들을 메모리에 내장된 스케줄 내에 삽입할 수 있다. 스케줄 내의 특정 인스트럭션의 위치는 적어도 부분적으로 트리 구조(313)와 연관된 처리 과정 순서에 의존한다.
스케줄 내에 만약 두 개 이상의 다른 I/O 요청들이 유사한 트리 구조들(313)을 포함하면, 이러한 I/O 요청들은 인터리브(interleave)되어 하나 이상의 요청이 동시에 처리될 수 있다. 이는 다음 I/O 요청의 처리 과정이 시작되기 전에 각각의 I/O 요청 처리 과정이 완료될 때까지 기다리지 않고, 연관된 I/O 요청들이 동시 또는 겹치는 시간에 완료될 수 있어서 I/O 요청들을 수행하는 데에 효율성을 증진시킬 수 있다. 예를 들어 어떠한 실시예들에 있어서, 트리 구조(313)의 인스트럭션들과 인터리브된, 다른 I/O 요청들로부터의 하나 이상의 인스트럭션들은 트리 구조(313)의 인스트럭션들을 실행하는 과정과 병렬적으로 실행될 수 있다.
한 예로서 이로 한정되지는 않지만, I/O 요청들이 인터리브될 경우 더욱 빠르게 처리될 수 있는 것으로 스케줄러(303)가 판단하면, I/O 요청들은 인터리브될 수 있다. 이는 하기 두 개의 예를 참조하여 설명될 수 있다.
첫 번째 예에 따라 두 개의 패치된(patched) 판독 과정들이 동시에 실행되는 것으로 가정한다. A 파일은 다섯 개의 청크들, (A1) (A2) (P1) (A3) (P2), 을 필요로 한다. B 파일은 네 개의 청크들, (B1) (P3) (B2) (B3), 을 필요로 한다. 이 때 'P'는 패치(patch) 파일을 대표하고 'A'와 'B'는 원래의 데이터 파일들을 가리킨다. 디스크 상의 레이아웃(layout)은 하기와 같을 수 있다.
... (A1) (A2) (A3) ... (B1) (B2) (B3) ............. (P1) (P2) ...
디스크 상의 파일들의 근접성(proximity) 때문에, 스케줄러(303)는 최소한의 탐색 과정을 통해 가장 빨리 두 개의 판독 과정 모두를 완료할 수 있는 방법은 A1 내지 A3을 먼저 판독하고, 그 다음 B1 내지 B3을, 그런 다음 P1 내지 P3을 판도함으로써, 두 요청들을 인터리브하는 것으로 판단할 수 있다.
두 번째 예에 따라 스케줄러(303)가 제 1 판독 요청과 높은 우선순위와 낮은 대기 시간(low-latency)을 가진 제 2 판독 요청을 스케줄한 것으로 가정한다. FIOS(101)는 하기 표 1에 도시된 바와 같이 제 1 판독 과정에서의 청크들부터 처리해 나갈 수 있다. 표 1에서는 시간이 지남에 따라 청크들이 좌측으로 움직인다. 청크들은 큐(queue)에서 시작하고, 실행 과정으로 이동한 다음, 마지막으로 완전히 완료된다.
done executing in queue
(A1) (A2) (A3) (A4) (A5) (A6) (A7) (A8)
A3을 실행하는 과정이 시작된 후, 큐는 아래 표 2에 도시된 바와 같을 수 있다.
done executing in queue
(A1) (A2) (A3) (A4) (A5) (A6) (A7) (A8)
이제 오디오 스레드(thread)가 수신되고 갑자기 (B1)과 (B2)를 로드하기 원하는 것으로 가정한다. 만약 오디오 판독기가 즉각적인 처리를 요구한다면, 스케줄러(303)는 (B1)과 (B2)의 판독 과정을 큐의 앞 쪽에 위치시킬 수 있다. 이 때 큐는 아래 표 3과 같이 보여질 수 있다.
done executing in queue
(A1) (A2) (A3) (B1) (B2) (A4) (A5) (A6) (A7) (A8)
마지막으로, 큐의 이러한 부분이 실행되는 과정이 종료되면 두 개의 판독 요청들을 위하여 I/O 요청들이 인터리브 된 것으로 표 4와 같이 보여질 수 있다.
done executing in queue
(A1) (A2) (A3) (B1) (B2) (A4) (A5) (A6) (A7) (A8)
(종종 미디어 접속 계층으로 불리는) 장치 미디어 계층(307)은 상기의 미디어 필터 계층들(305)로부터 수신된 미디어 요청들에 반응하도록 설정될 수 있다. 따라서 장치 미디어 계층(307)은 요청된 데이터를 추출하고, 그런 다음 응답을 스택(300)으로 송신한다.
미디어 필터 계층들(305)은 페처(patcher)(322), 디아카이버 계층(308), RAM 캐시 계층(31), 스케줄러 캐시 계층(312), 오버레이(overlay) 계층(314), 카탈로그(catalog) 캐시 계층(316), 부호화 또는 복호화 계층(318) 및 압축 또는 복원화 계층(320)을 포함할 수 있다. 이러한 미디어 필터 계층들(305)은 트리 구조(313)와 연관된 처리 계층들(306)에 대응한다. I/O 요청과 연관된 특정 데이터 일부분은 데이터와 연관된 미디어 필터 계층들의 수에 따라 다수의 처리 계층들을 가질 수 있다. 디아카이버(308)는 압축된 아카이브들(archives)로부터 특정 자산 파일들(asset files)을 추출하는 과정을 용이하게 하는데 사용될 수 있다. RAM 캐시 계층(310)은 일례로, 메인 메모리에 캐시된 데이터를 구현하는 데에 사용될 수 있다. 스케줄러 캐시(312)는 광 디스크와 같이 비교적 느린 소스로부터의 데이터를 임시 저장하기 위해 간단한 디스크 대 디스크(disc-to-disc) 캐시가 될 수 있다. 본 명세서에서 사용된 '스케줄러 캐시'라는 용어는 미디어 장치 보다는 빠르게 접속할 수 있는 저장 매체 내의 임시 데이터 저장소를 가리킨다. 스케줄러 캐시(312) 내에 있는 모든 데이터가 프리페치(pre-fetch) 될 필요는 없다. 어떠한 데이터는 요구가 있는 즉시 패치(patched)되고 캐시로 카피될 수 있다. 일례로 이로 한정되지는 않지만, 스케줄러 캐시 계층(312)은 급속 저장 매체를 이용하여 이러한 임시 저장소를 제공한다. 급속 저장 매체가 하드 디스크 드라이브(HDD)인 특정 경우에 있어서, 스케줄러 캐시(312)는 때때로 HDD 캐시로 불린다.
스케줄러 캐시(312)는 단일 또는 다수의 파일로 보유될 수 있다. 또한 스케줄러 캐시(312)의 콘텐츠가 파일들 전체가 될 필요는 없다. 다수의 파일로 된 캐시는 지나친 데이터를 희생하지 않고도, 필요 시 디스크 공간을 지능적으로 비우기 위해 약간의 파일들 각각을 삭제함으로써, 부분적으로 플러쉬(flush)될 수 있다. 이에 대비하여, 단일의 파일로 된 캐시는 일반적으로 절단되거나(truncated), 전체적으로 삭제될 뿐이다. 단일의 파일로 된 캐시는 다수의 파일로된 캐시들보다 더 높은 성능을 제공할 수 있다. 이는 다수의 파일로 된 캐시는 주로 별도의 I/O를 필요로하는 추가적인 (호스트 파일 시스템 자체 내에서)부기(bookkeeping) 작업을 요구하기 때문이다.
오버레이 계층(314)은 하술된 바와 같이 파일 시스템 레벨에서 파일 및 디렉토리들이 임의로 오버레이 되도록 하는데 사용될 수 있다. 카탈로그 캐시 계층(316)은 처리부나 셀 프로세서의 O/S가 올바르게(properly) (예. 파일 존재, 크기 및 위치)캐시하지 않은 데이터를 캐시하는데 사용될 수 있다. 복호화또는 부호화 계층(318)은 전송을 위한 데이터의 복호화나 부호화 과정을 용이하게 하는데 사용될 수 있다. 압축 또는 복원화 계층(320)은 전송을 위한 데이터를 압축하거나 복원하는 과정을 용이하게 하는데 사용될 수 있다.
FIOS 프로그램(101)의 트리 구조 계층(301) 및 스케줄러(303)의 운용 과정은 하술된 도 4를 참조하여 설명한다. 클라이언트의 관점에서 볼 때 I/O 요청(403)은 비교적 단순한 방식으로 수행될 수 있다. 예를 들어 비디오 게임과 같은 어플리케이션(401) 내의 스레드(402)는 기능(예. readFile())을 불러서 FIOS 프로그램(101)을 통하여 I/O를 요청할 수 있다. 이러한 기능은 I/O 요청(403)의 우선순위와 요청(403)이 완료되어야할 기한을 명시할 수 있다. 이에, FIOS 미디어 스택(300)은 이러한 I/O 요청(403)을 위한 최적의 처리 순서를 지정하는 맵을 형성하는, I/O 요청(403)을 위한 트리 구조(313)를 생성하는데 트리 구조 계층(301)을 사용한다.
트리 구조는 우선 특정 I/O 요청(403)과 연관된 처리 과정의 레벨(306)을 정한다. 예를 들어, 특정 I/O 요청(403)은 프로세서에서 미디어 장치로 데이터를 전송하도록 요청할 수 있다. 이러한 데이터는 압축되고, 부호화되고, 아카이브 될 필요가 있다. 이러한 경우에 있어서, 트리 구조(313)는 I/O 요청(403)과 연관된 데이터의 압축 과정, 부호화 과정 및 아카이브 과정을 위한 처리 과정의 세 가지 레벨(306)을 지정할 것이다. 데이터의 특정 부분은 부호화 되기 전에 압축되어야만 하고, 아카이브 되기 전에 부호화 되어야 하며, 마침내 미디어 장치로 전송되기 전에 아카이브 되어야 한다.
그런 다음 트리 구조(313)는 처리 과정의 레벨(306)에 따라 전송될 데이터를 청크들(302)로 나눈다 (예. 압축 레벨에서 데이터는 64K의 청크들로 나뉘고, 부호화 레벨에서 데이터는 다양한 크기의 청크들로 나뉘며, 아카이브 레벨에서 데이터는 64K의 청크들로 나뉜다). 데이터는 청크들(302)로 나뉘어서, 어떠한 특정 레벨이나 다른 레벨에서 데이터의 일부분들이 다음 레벨의 처리 과정(306)이 시작하기 전에 요청에 포함된 모든 데이터가 현재 레벨의 처리 과정(306)을 마칠 때 까지 기다리지 않고도 동시에 처리될 수 있다. 하나의 처리 과정 레벨(306)의 청크들(302)이 다른 처리 과정 레벨(306)의 청크들(302)과 라인업 할 필요가 없기 때문에, 다른 처리 과정 레벨들(306)에 대응하는 청크들(302)의 데이터 종속성(304)이, I/O 요청(403)의 처리 과정을 간소화하기 위해 매핑 되어야만 한다. 예를 들어 특정 압축 레벨의 청크의 압축 과정이 완료되자마자 항상 부호화 과정이 시작되지 않을 수 있다. 부호화 레벨이 다양한 크기에서 처리되기 때문에, 두 개 이상의 압축 레벨의 청크들은 부호화 레벨의 청크가 부호화 과정을 시작하기 전에 압축되어야 할 수 있다. 그러므로, 특정 I/O 요청(403)이 처리 과정을 최적화하기 위해 트리 구조(313)가 이러한 데이터 종속성들(304)을 판단하는 것은 필수이다. 이에 더하여 I/O 요청이 다수의 미디어나 저장 장치들로부터의 데이터 추출을 요구할 때, 트리 구조(313)에 개설(槪說)(outline)된 데이터 종속성(304)은 하나의 미디어나 저장 장치로부터의 데이터가 처리되는 동안 다른 미디어나 저장 장치가 대기할 필요 없이, 다른 미디어나 저장 장치들로부터의 데이터가 동시에 처리되도록 한다.
트리 구조(313)와 연관된 마지막 산출물은, 특정 I/O 요청(403)을 처리하기 위한 최적의 순서를 지정하는 맵이다. I/O 요청 스케줄의 최적화에도 불구하고 I/O 요청들(403) 각각은 트리 구조(313)에 의해 각각 최적화 됨으로써, 가능한 최단 시간 내에 완료될 수 있다. 그런 다음 이러한 I/O 요청(403)과 그와 연관된 트리 구조(313)가 효율적인 스케줄링을 위해 스케줄러(303)에 입력된다.
I/O 요청과 연관된 데이터는 상술된 두 개의 계층들보다 더 많은 처리 과정의 계층들을 가질 수 있다는 점을 염두해 두어야 한다.
일례로 이에 한정되지는 않지만, I/O 요청은 이러한 요청을 처리하는 각각의 계층에 있는 데이터의 청크들 각각이 그에 대응하는 인스트럭션에 의해 취급될 수 있는 트리 구조로 나누어 질 수 있다. 트리 구조의 하나의 계층 내에 있는 특정 인스트럭션은 특정 인스트럭션을 실행하는 과정이 시작되기 전에 완료되어야만 하는 이전 계층으로부터의 하나 이상의 인스트럭션을 표시하는 데이터 종속성들을 가질 수 있다.
표 5는 I/O 요청을 위한 트리 구조의 일례를 제공한다. 표 1에 있어서, 각각의 인스트럭션은 경로 이름, 오프셋 및 킬로바이트(KiB) 길이로 식별되는 데이터를 사용한다. 이번 예에 있어서, 트리 구조 내의 계층들을 처리하는 순서는 상향식(from bottom to top)이다. 한편 트리 구조 내의 인스트럭션들은 데이터 종속성들이 충족되는 범위까지 병렬적으로 실행될 수 있다. 표 5에 있어서, 특정 인스트럭션의 종속성은 특정 인스트럭션을 실행하는 과정이 시작하기 전에 어떤, 다른 인스트럭션(들)이 하위층에서 완료되어야하는지 표시한다. 이번 예에서, '/dev_'로 시작하는 경로 이름들은 미디어 장치들을 가리킨다. 특히 '/dev_hdd0'과 '/dev_hdd1'은 하드 디스크 드라이브들을 가리키고, '/dev_bdvd0' 은 고화질 디지털 비디오 드라이브(DVD)를 가리킨다. '/dev_'로 시작하지 않는 경로 이름들은 다른 인스트럭션들에 의해 추출된 데이터를 구성하는 가상 파일들을 가리킨다.
Instruction # (name, offset, length (KiB)) dependency
0 (/userfile.dat, 0, 1200) 1, 2, 3, 4
Patcher Chunking Layer
1 (/userfile.dat, 0, 400) 5-11
2 (/xxx.pspatch, 1, 1) 12
3 (/userfile.dat, 800, 400) 13-19
4 (/xxx.pspatch, 2, 399) 12, 20-25
De-archiver Chunking Layer
5 (/userfile.dat, 0, 64) 26
6 (/userfile.dat, 64, 64) 27
7 (/userfile.dat, 128, 64) 28
8 (/userfile.dat, 192, 64) 29
9 (/userfile.dat, 256, 64) 30
10 (/userfile.dat, 320, 64) 31
11 (/userfile.dat, 384, 64) 32
12 (/xxx.pspatch.dat, 0, 64) 33
13 (/userfile.dat, 768, 64) 34
14 (/userfile.dat, 384, 64) 35
15 (/userfile.dat, 384, 64) 36
16 (/userfile.dat, 384, 64) 37
17 (/userfile.dat, 384, 64) 38
18 (/userfile.dat, 384, 64) 39
19 (/userfile.dat, 384, 64) 40
20 (/xxx.pspatch.dat, 64, 64) 41
21 (/xxx.pspatch.dat, 128, 64) 42
22 (/xxx.pspatch.dat, 192, 64) 43
23 (/xxx.pspatch.dat, 256, 64) 44
24 (/xxx.pspatch.dat, 320, 64) 45
25 (/xxx.pspatch.dat, 384, 64) 46
De-archiver Transform Layer (decompression)
26 (game.psarc, 500, 27) 47-48
27 (game.psarc, 527, 35) 48
28 (game.psarc, 562, 31) 48
29 (game.psarc, 593, 17) 48
30 (game.psarc, 610, 50) 48-49
31 (game.psarc, 660, 38) 49
32 (game.psarc, 698, 34) 49
33 (patch.psarc, 100, 19) 50
34 (game.psarc, 1132, 18) 51
35 (game.psarc, 1150, 18) 51-52
36 (game.psarc, 1182, 29) 52
37 (game.psarc, 1211, 29) 52
38 (game.psarc, 1240, 64) - uncompressed 52-53
39 (game.psarc, 1304, 40) 53
40 (game.psarc, 1442, 39) 53
41 (patch.psarc, 119, 64) uncompressed 50, 54
42 (patch.psarc, 183, 50) 54
43 (patch.psarc, 233, 17) 54
44 (patch.psarc, 250, 26) 54-55
45 (patch.psarc, 276, 35) 55
46 (patch.psarc, 311, 15) 55
Ram Cache Layer (128 KiB blocks)
47 (game.psarc, 384, 128) 56
48 (game.psarc, 512, 128) 57
49 (game.psarc, 640, 128) 58
50 (patch.psarc, 0, 128) 59
51 (game.psarc, 1024, 128) 60
52 (game.psarc, 1152, 128) 61
53 (game.psarc, 1280, 128) 62
54 (patch.psarc, 128, 128) 63
55 (patch.psarc, 256, 128) 64
Decryption Layer (128 KiB blocks)
56 (game.psarc, 384, 128) 65
57 (game.psarc, 512, 128) 66
58 (game.psarc, 640, 128) 67
59 (patch.psarc, 0, 128) 68
60 (game.psarc, 1024, 128) 69
61 (game.psarc, 1152, 128) 70
62 (game.psarc, 1280, 128) 71
63 (patch.psarc, 128, 128) 72
64 (patch.psarc, 256, 128) 73
Overlay Layer (path translation)
65 (/dev_bdvd/game.psarc, 384, 128) 74
66 (/dev_bdvd/game.psarc, 512, 128) 75
67 (/dev_bdvd/game.psarc, 640, 128) 76
68 (/dev_hdd/game.psarc, 0, 128) 77
69 (/dev_bdvd/game.psarc, 1024, 128) 79
70 (/dev_bdvd/game.psarc, 1152, 128) 81
71 (/dev_bdvd/game.psarc, 1280, 128) 83
72 (/dev_hdd/game.psarc, 128, 128) 96
73 (/dev_hdd/game.psarc, 256, 128) 97
HDD cache Layer (Decide hit/fill/readthru)
74 (/dev_hdd1/cache.dat, 16384, 128) hit
75 (/dev_hdd1/cache.dat, 16512, 128) hit
76 (/dev_hdd1/cache.dat, 16640, 128) hit
77 (/dev_hdd0/patch.psarc, 0, 128) RT
78 (/dev_hdd1/cache.dat, 17024, 128) write fill 94, 79
79 (/dev_bdvd/game.psarc, 1024, 128) read fill
80 (/dev_hdd1/cache.dat, 17152, 128) write fill 94, 81
81 (/dev_bdvd/game.psarc, 1152, 128) read fill
82 (/dev_hdd1/cache.dat, 17280, 128) write fill 94, 83
83 (/dev_bdvd/game.psarc, 1280, 128) read fill
84 (/dev_hdd1/cache.dat, 17408, 128) write fill 94, 85
85 (/dev_bdvd/game.psarc, 1408, 128) read fill
86 (/dev_hdd1/cache.dat, 17536, 128) write fill 94, 87
87 (/dev_bdvd/game.psarc, 1536, 128) read fill
88 (/dev_hdd1/cache.dat, 17664, 128) write fill 94, 89
89 (/dev_bdvd/game.psarc, 1664, 128) read fill
90 (/dev_hdd1/cache.dat, 17792, 128) write fill 94, 91
91 (/dev_bdvd/game.psarc, 1792, 128) read fill
92 (/dev_hdd1/cache.dat, 17920, 128) write fill 94, 93
93 (/dev_bdvd/game.psarc, 1920, 128) read fill
94 (/dev_hdd1/cache.idxm 32, 1) write update
//initial write of index marking block busy//
95 (/dev_hdd0/patch.psarc, 128, 128) write update
//final write of index marking block's VRW controls//		 80, 82, 84, 86, 88, 90, 92, 94
96 (/dev_hdd0/patch.psarc, 128, 128) RT
97 (/dev_hdd0/patch.psarc, 256, 128) RT
표 5에 나타난 예에 있어서, 파일을 요청하는 I/O 요청은 DVD에서 송신된 것이다. 이번 예에서의 트리 구조 내에 있는 계층들 각각은 상향식 순서로 실행된다. 이는 최하위 층에 있는, 적어도 일부의 인스트럭션들이 데이터 종속성으로 인해 우선적으로 실행되어야만 한다는 것을 의미한다. 본 명세서에 사용되는 '최하위 층'이라는 용어는 구조 중 이전 또는 더 아래에 있는 계층이 없는 계층을 일컫는다. 이전 또는 더 아래에 있는 계층이 없는 계층이라는 의미는 최하위 계층에 있는 어떠한 인스트럭션도 다른 계층에 있는 인스트럭션의 실행이 완료되는 것을 요구하지 않는다는 의미이다. 그러나 최하위 계층에 있는 하나 이상의 인스트럭션들은 최하위 계층에 있는 다른 인스트럭션들의 실행이 완료되는 것을 요구하는 데이터 종속성을 가질 수 있다.
표 1을 참조하여 서술된 예에 있어서, 최하위 계층은 HDD 캐시 계층이다. 표 5에 포함된 인스트럭션들이 수행되는 정확한 순서는 HDD 캐시 계층에 있는 인스트럭션들 내의 데이터 종속성들에 어느 정도 의존할 수 있다. 일례로 표 5에서의 HDD 캐시 계층에 있는 마지막 I/O 요청들은 하기 표 6에 도시된 실행 순서로 장치 또는 파티션(partition)에 의해 분류될 수 있다.
Instruction # (name, offset, length (KiB)) dependency
94 (/dev_hdd1/cache.idxm 32, 1) write
74 (/dev_hdd1/cache.dat, 16384, 128) read
75 (/dev_hdd1/cache.dat, 16512, 128) read
76 (/dev_hdd1/cache.dat, 16640, 128) read
78 (/dev_hdd1/cache.dat, 17024, 128) write * 94, 79
80 (/dev_hdd1/cache.dat, 17152, 128) write * 94, 81
82 (/dev_hdd1/cache.dat, 17280, 128) write * 94, 83
84 (/dev_hdd1/cache.dat, 17408, 128) write * 94, 85
86 (/dev_hdd1/cache.dat, 17536, 128) write * 94, 87
88 (/dev_hdd1/cache.dat, 17664, 128) write * 94, 89
90 (/dev_hdd1/cache.dat, 17792, 128) write * 94, 91
92 (/dev_hdd1/cache.dat, 17920, 128) write * 94, 93
95 (/dev_hdd0/patch.psarc, 128, 128) write * 78, 80, 82, 84, 86, 88, 90, 92
77 (/dev_hdd0/patch.psarc, 0, 128) read
96 (/dev_hdd0/patch.psarc, 128, 128) read
97 (/dev_hdd0/patch.psarc, 256, 128) read
79 (/dev_bdvd/game.psarc, 1024, 128) read
81 (/dev_bdvd/game.psarc, 1152, 128) read
83 (/dev_bdvd/game.psarc, 1280, 128) read
85 (/dev_bdvd/game.psarc, 1408, 128) read
87 (/dev_bdvd/game.psarc, 1536, 128) read
89 (/dev_bdvd/game.psarc, 1664, 128) read
91 (/dev_bdvd/game.psarc, 1792, 128) read
93 (/dev_bdvd/game.psarc, 1920, 128) read
표 6에 포함된 인스트럭션들 중 스케줄러(303)에 의해 분류되고 디스패치(dispatch) 될 수 있는, (*)로 표시된, 종속성을 가진 것들을 제외한 나머지 모두는 병렬적으로 발행(issue)될 수 있다. 특히 인덱스(index) 기록 인스트럭션 94 및 판독 인스트럭션들 77, 79, 81, 83, 85, 87, 89, 91 및 93은 어떠한 데이터 종속성도 가지고 있지 않기 때문에, 이러한 인스트럭션들은 병렬적으로, 그리고 아무런 순서에 따라 실행될 수 있다. 기록 인스트럭션들 78, 80, 82, 84, 86, 88, 90 및 92는 초기 인덱스 기록 인스트럭션 94와 각각의 판독 인스트럭션들 77, 79, 81, 83, 85, 87, 89, 91 및 93에 종속된다. 결과적으로 이러한 기록 인스트럭션들 각각은 인덱스 기록 인스트럭션 94와 대응하는 판독 인스트럭션이 실행될 때까지 기다려야만 한다.
표 5에 설명된 트리 구조에 있는 나머지 인스트럭션들은 데이터 종속성이 충족되는 범위까지 병렬적으로 실행될 수 있다. I/O 요청을 수신한 후 즉시 생성된 트리 구조 내에 데이터 종속성을 포함시킴으로써, 트리 구조의 특정 계층에 있는 인스트럭션 각각은 이러한 인스트럭션의 데이터 종속성의 요구 사항들이 충족되는 즉시 실행될 수 있다. 이에 따라 인스트럭션 각각의 데이터 종속성들이 충족되기만 한다면, 두 개의 상이한 계층들에 대한 인스트럭션들을 병렬적으로 실행할 수 있다. 따라서 하나의 계층에서의 인스트럭션은 그 계층에 있는 모든 인스트럭션들이 완료될 때까지 기다릴 필요가 없다.
예를 들어 I/O 요청을 실행하기 위해서는 인스트럭션 0 과, 패처(patcher) 인스트럭션들 1, 2, 3, 4 가 먼저 완료되어야만 한다. 패처(patcher 인스트럭션 4 가 실행될 수 있기 전에, 디아카이버 인스트럭션들 12 및 20 내지 25 가 완료되어야 한다. 디아카이버 인스트럭션 25 가 실행될 수 있기 전에, 복원 인스트럭션 46 만 완료되어야 한다. 복원 인스트럭션 46 이 시작될 수 있기 전에, 램 캐시 인스트럭션 55 만 완료되어야 한다. 램 캐시 인스트럭션 55 가 시작될 수 있기 전에, 복원 인스트럭션 64 만 완료되어야 한다. 복원 인스트럭션 64 이 시작될 수 있기 전에, 오버레이(overlay) 인스트럭션 73 이 완료되어야 한다. 오버레이 인스트럭션 73 이 시작될 수 있기 전에, HDD 캐시 인스트럭션 97 만 완료되어야 한다.
I/O 요청(403)이 트리 구조 계층(301)을 통과하고, 이러한 특정 I/O 요청을 위한 처리 순서가 결정되고 나면, I/O 요청(403)은 스케줄러(303)에 의해 인커밍 큐(404)로 이동한다. 예를 들면, 인커밍 큐(404)는 큐(404)에 첫 번째로 넣어진 요청이 스케줄러(303)에 의해 스케줄되는 첫 번째 요청이 되는, 선입선출법(first-in-first-out; FIFO)을 사용하는 큐가 될 수 있다. 요청(403)을 인커밍 큐(404)에 삽입하는 과정은 비동기식(asynchronous) I/O를 요청할 때 스레드들이 차단되는 것을 방지하는, 원자적 연산(atomic operation)에 의해 구현될 수 있다. 어떠한 실시예들에 있어서, 인커밍 큐(404)는 보조 프로세서(105B)에 의해 원자적 교환으로 채워질 수 있는 원자적 스택의 형태를 가질 수 있다.
예컨대 이로 한정되는 것은 아니지만, I/O 요청(403)이 판독 과정을 요청하면, 클라이언트 어플리케이션(401)은 미디어 장치로부터 추출한 데이터를 수신하는 버퍼(405)를 공급할 수 있다. I/O 요청(403)이 완료될 때, 클라이언트 어플리케이션(401)은 공급한 버퍼(405)에서 추출된 데이터를 판독할 수 있다. 클라이언트가 I/O 요청(403)을 처리하는 과정을 마칠 때, 클라이언트는 버퍼(405)를 할당해제(de-allocate)해서 그의 리소스들이 미래에, I/O 용도로 사용될 수 있도록 한다.
I/O 요청(403)은 스케줄러(303)가 이미 활성화되지 않은 경우, 스케줄러(303)를 활성화한다. 그런 다음 어플리케이션(401)은 완료될 I/O 요청(403)을 기다릴 수 있다. 예를 들면, 클라이언트 어플리케이션(401)은 원자적 방법(예. isDone())을 사용하여 주기적으로 폴링(polling)한다. 선택적으로, 클라이언트는 I/O 요청(403) 완료 시, FIOS 프로그램(101)가 부르는 콜백 기능(411)을 기다릴 수 있다.
I/O 요청(403)이 인커밍 큐(404)에 삽입된 후, FIOS 프로그램(101)은 스케줄러(303)가 스케줄 삽입 과정(407)을 수행하도록 유발할 수 있다. 스케줄러(303)에 의해 구현되는 과정들의 순서는 도 5를 참조하여 서술된다. 스케줄러(303)는 502 과정에 표시된 바와 같이 처리할 I/O가 없으면 슬립 상태(sleep)(즉, 비활성화 상태 유지)에 있을 수 있다. 새로운 I/O 요청(403)이 인커밍 큐(404)에 진입할 때 스케줄러(303)는 이를 처리하기 위해 어웨이크(awake) 한다. 스케줄러(303)가 어웨이크 한 후( 또는 이미 어웨이크한 경우), 스케줄러(303)는 인커밍 큐(404)에 있는 새로운 요청(403)을 인지하고, 스케줄 큐(406)의 적합한 위치로 요청을 이동시킨다.
I/O 요청(403)의 큐 위치를 결정하기 위해 스케줄러(303)는 선택적으로 503 과정에 표시된 바와 같이 예를 들어 장치 미디어 계층(307)이나 FIOS 미디어 스택(300)에 있는 다른 계층을 조회(query)함으로써, 미디어 장치의 현재 상태를 파악할 수 있다. 상태를 나타내는 데이터는 FIOS 미디어 스택(300)에 의해 취급되는 미디어 장치의 종류와 스택(300)에 존재하는 다양한 계층들에 따라서 달라질 수 있다. 예로 포함되는 것으로는 최근에 접속된 논리 블록 주소(logical block address; LBA), RAM 캐시의 마지막으로 접속된 경로 및 오프셋, 현재 디스크 계층, 헤드(head) 위치, 스트리밍(streaming) 모드 및 비스트리밍(non-streaming) 모드 등이 있다.
본 발명의 실시예들에 따르면 스케줄러(303)는 미디어 장치 성능 모델(303A)에 기초할 수 있다. 현재의 I/O 스케줄러들과는 다르게, 드라이브 모델(303A)은 요청(403)을 처리하기 위한 최적의 스케줄을 결정하는데 있어서 미디어 장치(118)의 성능에 관한 데이터를 참조할 수 있다. 드라이브 모델을 사용하여 I/O 요청들(403)을 스케줄하는 과정은 CD를 생성하는 데에 있어서 마스터링 처리 과정이 도치(倒置)(inverse)된 과정에 비교될 수 있다. 성능 모델(303A)은 오버헤드(overhead), 디스크 이동 시간, 판독 시간 등과 같은 요소들을 고려하도록 설정될 수 있다. 성능 모델(303A)은 처리량(throughput), 레이저의 흔들림(wiggles), 판독 헤드의 움직임, 레이어 변경 및 요청 오버헤드와 같은 미디어 장치(118)의 임의로 복잡한 특성들을 모델링할 수 있다. 또한 성능 모델(303A)은 I/O 요청에 연관된 미디어 장치(118)에 의해 판독되거나 기록되는 특정 매체의 다른 파라미터들을 참조할 수 있다. 예를 들어, 성능 모델(303A)은 장치가 단일 레이어 디스크나 다수 레이어 디스크(예. 블루 레이 DMD와 같은 듀얼 레이어 디스크)를 판독하는 지 고려할 수 있다.
또한 스케줄러(303)는 504 과정에 표시된 바와 같이 새로운 I/O 요청의 시간 요구 사항들(예. 기한)과 우선순위를 선택적으로 참조할 수 있다. 이에 더하여 스케줄러는 506 과정에 표시된 바와 같이, 인터리브(interleave)하기 위해 인커밍 큐(404)에 있는 I/O 요청들을 스케줄 큐(406)에 있는 I/O 요청들과 비교하도록 선택적으로 설정될 수 있다. 인커밍 큐(404)에 있는 특정 I/O 요청의 트리 구조(313)에 의해 개설(槪說)(outline)된 데이터 종속성들(304)은 스케줄 큐(406)에 이미 배치된 하나 이상의 I/O 요청들의 트리 구조들(313)에 의해 개설(槪說)(outline)된 트리 구조들과 겹칠(overlap) 수 있다. 예를 들어, 인커밍 큐(404)에 있는 I/O 요청은 특정 미디어 장치로부터의 데이터 청크를 판독해야될 수 있고, 스케줄 큐(406)에 있는 I/O 요청은 동일한 미디어 장치로부터의 인접한 데이터 청크를 판독해야 될 수 있다. 그러므로 이러한 두 개의 I/O 요청들을 인터리브함으로써, 이러한 I/O 요청들을 처리하는 과정의 효율성이 증진될 수 있다. 인터리브하는 과정은 두 개의 특정 트리 구조들(313) 사이의 오버랩(overlap) 임계 값을 설정함으로써 이루어질 수 있고, 오버랩 임계 값이 충족되면, 이러한 트리 구조들(313)과 연관된 두 개의 I/O 요청들을 인터리브할 수 있다. 두 개 이상의 I/O 요청들이 인트리브 된 경우에는, 스케줄러가 스케줄링 하는 동안에 이렇게 인터리브 된 요청들을 단일의 요청으로 취급할 수 있다.
어떠한 I/O 요청들이 인트리브 될 지 결정된 다음, 스케줄러(303)는 507 과정에 표시된 바와 같이 현제 I/O 요청을 위한 큐에서의 최고의 위치를 판단할 수 있다. 스케줄러(303)는 스케줄 큐의 임의의 위치에 인커밍 I/O 요청을 배치시킴으로써 시작할 수 있다. 이에 전체 스케줄을 완료하고 우선순위까지 감안하는 데 필요한 총 시간과 기한 제약들은 이러한 시범적 스케줄 큐를 사용하여 파악된다. 이러한 과정은 507 과정에 표시된 바와 같이 최고의 스케줄 큐 순서를 판단할 때 까지 다른 큐 순서들을 가지고 반복적으로 재수행 될 수 있다. 요청(403)의 초기 상태는 스케줄 순서에 있는 이전 요청을 위한 마무리 상태로부터 판단될 수 있고, 스케줄 순서에 있는 다음 요청을 위한 초기 상태는 요청(403)의 마지막 상태에서 판단될 수 있다.
스케줄러(303)는 스케줄 큐에 있는 요청들을 하나씩 처리해 나갈 수 있다. 이 때 스케줄러(303)는 요청(403)의 특징들을 이미 큐에 있는 요청들과 비교할 수 있다. 스케줄러(303)는 큐에서 가능한 위치들 각각에 요청(403)을 배치해볼 수 있다. 이 때 스케줄러(303)는 우선순위를 무효화하는 과정(overrides), 놓친 기한들 및 시간 참작(time consideration)을 찾아볼 수 있다. 스케줄러(303)는 어떠한 요청된 I/O 과정도 기한을 놓치지 않는 순서를 검색함으로써 가장 최고의 새로운 큐 순서를 판단할 수 있다. 만약 하나 이상의 요청들이 기한을 놓치면, 스케줄러는 다른 기준을 사용하여 큐 순서를 결정 할 수 있다. 스케줄 큐(406)에 있는 요청들의 순서에 영향을 줄 수 있는 추가적인 기준으로는 이에 제한되지는 않지만, I/O 요청 우선순위들, 스트림 버퍼 상태들, 대기(latency) 요건들 및 다른 I/O 요청들의 트리 구조들 사이 겹치는 데이터 종속성들이 될 수 있다.
어떠한 실시예들에 있어서, 예를 들어 기한들 모두가 해결될 수 없는 경우, 우선순위가 사용될 수 있다. 예를 들면, 만약 어떠한 기한들이 불가피하게 맞춰질 수 없을 경우, 최고의 큐 순서는 최하위 우선순위를 가진 요청들의 기한을 충족시키지 않는 순서가 될 수 있다. 만약 이러한 고려 사항을 충족시키는 다수의 큐 순서들이 있을 경우에는 동일한 운선순위를 가진, 마감일이 충족되지 않는 최소수의 요청들을 가진 큐 순서가 최고의 순서가 될 수 있다. 나아가, 만약 상술된 제약들을 만족시키는 다수의 큐 순서들이 있는 경우에는, 큐 전체를 실행하는데 최단 시간이 소요되는 큐 순서가 최고의 순서가 될 수 있다. 어떤 경우들에 있어서, 높은 우선순위의 요청이 기한을 맞출 수만 있다면, 낮은 우선순위의 요청이 높은 우선순위의 요청 전에 스케줄링 될 수 있다.
상술된 모든 고려사항들을 만족시키는 다수의 큐 순서들이 있는 경우에는, 스케줄 큐(406)에 있는 최근 요청이 큐의 마지막으로 가는 순서가 최고의 순서가 될 수 있다.
스케줄러(303)가 요청(403)을 수행하기 위한, 스케줄 큐(406)의 최고 위치를 파악한 후에는, 도 4의 407 과정 및 도 5의 508 과정에 표시된 바와 같이 그곳에 요청이 삽입될 수 있다. 도 4를 다시 참조하면, I/O 요청들을 실행하기 위한 리소스들이 가용하면, 스케줄러(303)는 409 과정에 표시된 바와 같이 스케줄 큐(406)에 있는 첫 번째 요청을 발행 큐(408)로 이동시킬 수 있다. 이에 요청은 발행 큐(408)에서 실행될 수 있다. 특정 I/O 요청(403)을 실행하기 위해, 스케줄러(303)는 요청(403)과 특정 요청(403)과 연관된 트리 구조(313)을 FIOS 미디어 스택(300)에 있는 첫 번째 계층으로 보낼 수 있다.
스케줄러(303) 아래 계층들 각각은 상위 계층에서 보내진 I/O 요청(403)과 대응하는 트리 구조를 볼 수 있다. 적합한 경우, 계층은 요청과 연관된 데이터 청크들(304)을 처리할 수 있다. 각각의 계층들은 요청(403)과 연관된 트리 구조(313)에 따라 요청(403)을 처리해서, 요청은 가장 효율적인 방식으로 처리된다. 예를 들면, 이에 제한되지 않지만, 요청이 판독 과정일 경우, 디아카이버 계층(308)이 보급된 경로 이름을 오픈 아카이브 콘텐츠들과 비교하고, 만약 파일을 찾으면, 압축된 데이터를 판독하는 것으로 요청을 다시 매핑할 수 있다. FIOS 미디어 스택(300)의 계층들 각각은 처리되거나 처리되지 않은 I/O 요청이 끝내 하드웨어 계층(310)에 다다를때 까지 다음으로 낮은 계층에 I/O 요청을 넘긴다. 하드웨어 계층(310)이 요청에 응할 때, 그 응답은 미디어 스택(300)에 있는 각각의 계층들을 상향식으로 통과하고, 적합하다면, 각각의 계층들은 추출된 데이터의 청크들(302)을 처리할 수 있다. 예를 들면, 복원화 계층은 돌아온 데이터의 청크(302)가 복원되어야만 하는 것을 인지할 수 있고, 이에 따라 스택(300)으로 그 응답을 다시 보내기 전에 복원할 수 있다. 그 응답은 마지막으로 스케줄러(303)에게로 돌아간다.
추출된 데이터가 스택(300)으로 다시 올 때, 스케줄러(303)는 그것을 수신하고, (어플리케이션에 콜백 기능이 설정된 경우) 어플리케이션(401)에 콜백 기능(411)을 유발할 수 있는, 완료된 큐(410)로 I/O 요청(403)을 이동시킬 수 있다. 선택적으로, 어플리케이션(401)은 I/O 요청(403)이 완료되었는지 파악하기 위해 FIOS 스택(300)을 폴링 할 수 있다. I/O 요청(403)이 완료되고 나서는, I/O 요청(403)이 프리 I/O 풀(free I/O pool)(412)로 이동할 수 있다. 프리 I/O 풀(412)은 사용 중이지 않은 I/O 요청들 세트를 포함할 수 있다. 이러한 요청들은 클라이언트 어플리케이션(401)에 할당된 적이 전혀 없거나, 클라이언트 어플리케이션(401)에 의해 사용되었지만 재사용을 위하여 프리된(freed) 요청들일 수 있다. 클라이언트 어플리케이션(401)이 I/O 요청을 작성할 때 스케줄러(303)는 이러한 풀(412)에서 클라이언트에게 I/O 요청을 할당할 수 있다. 프리 I/O 풀(412)은 스택으로 구현될 수 있다. 프리 I/O 요청들은 프리 I/O 풀(412)에서 튀어 나오거나(popped) 인커밍 큐(404)에 넣어질 수 있다. 이러한 방식으로, 프리 I/O 요청들은 재사용될 수 있다.
본 발명의 실시예들에 따라, 스케줄러(303) 하술된 바와 같이 스케줄 루프(loop)에서 동작할 수 있다.
1. I/O 완료 여부 체크
2. 새로운 I/O 요청들 발행
3. (만약 있을 경우)I/O 콜백들 발행
4. 스케줄에 삽입(인커밍으로부터 스케줄에 삽입)
5. 다시 새로 발행
6. 추측된, 놓친 기한들 체크
7. 1.로 리턴.
각각의 반복들은 예를 들어, 최대 16번의 삽입 과정으로 스케줄 된 삽입 과정의 수가 제한될 수 있다.
본 발명의 어떠한 실시예들에 있어서, 보조 프로세서부(105B)(예. SPE(206))는 교환을 통해 인커밍 큐(404)로 인커밍 I/O를 위한 요청을 추가함으로써, 자체적으로 I/O를 요청할 수 있다. 이러한 교환은 메인 프로세서(105A)나 PPE(204)에 대하여 원자적이다. 예를 들어, 보편적인 셀 프로세서 구현 과정에 있어서, SPE(206)는 어떠한 I/O 기구들을 구비하지 않을 수 있다. 그러나 인커밍 큐(404)가 공통적인 데이터 엘리먼트이면, 보조 프로세서(105B)는 메인 프로세서(105A)와의 표준 원자적 교환을 통해 I/O 요청을 큐에 추가하고, 메인 프로세서(105A)에 신호를 보낼 수 있다.
종래의 많은 구현 방법들에 있어서, 만약 보조 프로세서(105B)가 즉각적인 처리를 위해 데이터를 필요로 한다면, 데이터는 메인 메모리에 있어야만 했다. 본 발명의 실시예들에 따르면, 반대로 보조 프로세서(105B)가 FIOS 미디어 스택(300)이 하드 미디어 장치(118)로 부터나 네트워크(127)를 통해서 까지도 필요한 데이터를 가져올 수 있도록 유발할 수 있다.
예를 들면 이로 제한되지 않지만, 인커밍 큐(404), 완료된 큐(410) 및 프리 I/O 풀(412)은 원자적 스택들이 될 수 있다. 보조 프로세서(105B)는 프리 I/O 풀(412)로부터 I/O 요청을 꺼내고, I/O 요청을 위한 경로를 기입하고, 요청을 인커밍 큐(404)로 다시 밀고(push), 그런 다음 동기화(synchronization)을 수행하고 스케줄러(303)를 어웨이크 시킨다. 보조 프로세서(105B)는 I/O 요청이 완료를 위해 간간이 폴링하지 않는 동안에는 다른 작업을 수행할 수 있다.
예를 들어, 셀 프로세서 시스템(200)에 있어서, I/O 요청은 PSE(206)에 의해 수행될 수 있다. SPE(206)에 의해 요청된 데이터는 PPE(204)에 의해 어드레스(address)로 불러낼 수 있는 어떤 곳으로도 전송될 수 있다. 만약 SPE(206)가 잠김 상태가 되면, FIOS 미디어 스택(300)은 SPE(206)의 로컬 저장부(LS)에 직접적으로 데이터를 기록할 수 있다. 어떠한 실시예들에 있어서, 하나의 SPE(206)는 복원화 계층이 다른 SPE와 복원화 과정을 수행하도록 요청할 수 있다. 이는 일례로 원격 프로시저 호출(remote procedure call; RPC)를 사용하여 프로세서들 사이에서 구현될 수 있다. 이번 예에 있어서, SPE(206)는 PPE(204)에게 이를 위해 무엇인가를 하도록 요청한다. 더 전통적인 RPC에서는, 반대로 수행된다.
어떠한 실시예들에 있어서, 스케줄러 캐시 계층(312)(예. HDD 캐시)는 미디어 장치(118)에서의 파일을 저장 장치(115)에 있는 캐시(117)로 프리페치(pre-fetch)하는데 사용되어서, 파일이 나중에 신속하게 판독될 수 있게 한다. 이러한 경우, 프리페치(pre-fetch) 과정(413)은 발행 큐(408)로 곧바로 삽입될 수 있다. 프리페치(pre-fetch) 과정은 파워 피씨(PowerPC) CPU 구조에 있는 'dcbt' 인스트럭션과 같은 많은 종류의 캐시들에 의해 구현되었던 표준 수동적 프리페치(pre-fetch) 과정이 될 수 있다. 본 발명의 실시예들에 따르면, 프리페치(pre-fetch)과정은 상술된 스케줄러 루프의 일부로 큐 되고 실행될 수 있다. 프리페치(pre-fetch) 과정은 비교적 높은 대기 시간(latency)와 낮은 처리량을 가지고, 다른 I/O 요청들이 수행되는 동안 접속되어야만 하는, 비교적 느린 소스 미디어(예. 블루 레이 및 UMD)와의 동작을 용이하게 할 수 있다.
스케줄러(302)는 이러한 프리페치(pre-fetch) 과정을 구현할 때 비교적 낮은 우선순위로 처리하도록 설정될 수 있어서, 이 과정은 미디어 장치(118)가 그렇지 않으면 대기 상태에 있을, 미사용 시에만 그리고 다른 I/O 요청들에게 방해되지 않을 때에 실행될 것이다. 예를 들어, 시스템(100)은 느린 미디어 장치(118)(예. 블루 레이 디스크(BD) 드라이브와 같은 광 디스크)와 하드 디스크 드라이브와 같은 비교적 급속 기억 장치(115)를 가진다. 스케줄러 캐시 계층(305)은 광 디스크 드라이브에서 하드 디스크로 파일을 비동기식으로 카피하는데 사용될 수 있다. 나중에 파일이 접속될 때 이 파일은 비교적 느린 광 디스크 속도(예. 8 MiB/s) 대신, 보다 더 높은 HDD속도(예. 20 MiB/s)로 판독될 것이다.
캐시 프리페치(pre-fetch) 과정은 보통 하드 디스크 캐시에서 수행되지만, 프리페치(pre-fetch) 과정은 메인 메모리(106, 202)에서도 수행될 수 있다. 프리페치(pre-fetch) 요청들은 스케줄 큐(406)의 마지막 부분에 포함될 수 있는데, 이 때 프리페치(pre-fetch) 요청들은 스케줄 과정 완료 후 수신된 순서에 따라 포함될 수 있다. 어떠한 실시예들에 있어서, 프리페치(pre-fetch) 요청들은 필요 시 지연될 수 있다. 프리페치(pre-fetch) 요청들은 다른 I/O 요청들(403)과 동일한 방식으로 스케줄링 되지 않는다. 프리페치(pre-fetch) 요청들은 스케줄 큐(406)가 빈(empty) 경우에만 운용되는, 분리된 프리페치(pre-fetch) 큐(413)에 수용된다. 프리페치(pre-fetch) 요청은 필요 시 지연될 수 있다. 그렇지 않으면, 프리페치(pre-fetch) 요청들은 수신된 순서에 따라 완료될 수 있다. 스케줄러(303)는 프리페치(pre-fetch) 요청들을 큐 내에 보유하다가 특정 시간 동안 I/O 서브시스템이 대기 중일 때만 실행할 수 있다. 이는 프리페치(pre-fetch) 요청들이 보통의 I/O 요청들을 방해하지 않도록 한다. 또한, 프리페치(pre-fetch) 요청들은 단일의 캐시 블록으로 제한되지 않으며, 그들은 어떠한 크기나 캐시가 파일 처음부터 끝까지, 파일 전체를 로드하도록 지시하는, 파일 전체 값의 크기도 가질 수 있다. 이에 더하여 프리페치(pre-fetch) 요청들이 어떠한 크기도 될 수 있지만, 프리페치(pre-fetch) 요청들은 FIOS 미디어 스택(300)이 지속적으로 대기 상토에 있는 지 체크하기 위해서 스케줄러(303)으로 리턴하기 전에 하나의 캐시 블록 까지만 채우도록 구현될 수 있다.
캐시 프리페치(pre-fetch) 과정은 비디오 게임과 같이 I/O 기반(driven) 어플리케이션들에서와 현재 비디오 게임 콘솔과 같이 특정 I/O 필요성을 가진 플랫폼들에서 증진된 I/O 성능을 제공할 수 있다. 특히 게임 데이터는 광학 매체나 네트워크 파일 서버와 같이 느린 매체에 주로 저장되지만, 게임은 HDD와 같이 빠른 로컬 저장부에 접속할 수 있다.
본 발명의 실시예들은 상당수의 I/O를 이용하는 어플레키이션 및 시스템들에서의 증진된 I/O 성능을 제공한다. 상술된 바와 같이 본 발명의 실시예들은 비디오 게임 어플리케이션들과 비디오 게임 시스템들에서 특히 유용하다. 그러나 본 발명의 실시예들은 이러한 어플리케이션들과 시스템들에 국한되지 않는다.
상술된 실시예들 이외의 변형예들이 본 발명의 실시예들의 범위 내에 있을 수 있다. 예를 들어 어떠한 구현 방법들에 있어서, 패처(patcher) 계층(322)에 의해 파일들을 패치(patch)하는 과정은 런타임(runtime)에서 적용되는 이진 차 패치(binary difference patch)들을 사용하여 구현될 수 있다. 예를 들면, 이진 차 패치(patch)들(119)은 저장부(115)에 저장되고, 런타임에서 관련된 파일들에게 적용될 수 있다.
전통적으로, 패치(patch)들은 네트워크를 통해 다운로드될 수 있는 차분 파일(difference file)로부터의 실행가능한 인스트럭션들을 따라 새로운 파일 전체를 생성함으로써, 적용되었다. 이러한 인스트럭션들은 어떤 바이트들(bytes)이 파일에서 제거되고, 어떤 바이트들이 파일에 추가될 것인지 표시할 수 있다. 저장부(115)에 저장된 이진 차 패치(patch)들(119)은 이러한 인스트럭션들을 포함할 수 있다. 패치(patch)하는 과정은 전통적으로 오프라인 상에서, 즉 런타임이 아닌 시간에, 수행되었다. 일반적인 전통 패치(patch)에 있어서, 원본 파일 전체는 저장부에서 메모리로 판독된다. 차분 패치들(difference patches)은 새로운 파일을 생성하기 위해 그 파일에 적용된다. 그런 다음 이러한 새로운 파일은 저장부에 기록된다. 이는 다운로드 할 패치(patch)의 크기를 최소화 하기 위한 것이었다.
차분 패치(patch)들은 300 보드(baud)나 1200보드(baud) 모뎀들에 의해 다운로드가 수행되었을 때에 개발되었다. 이 때에는 다운로드 량을 줄이는 것이 중요하였다. 인터넷의 발전으로 인해, 더 높은 다운로드 속도가 널리 사용되게 되었다. 이에 따라 차분 패치(patch)를 사용하지 않고도, 네트워크를 통해 파일 전체를 전송하고, 저장부(115)에 다운로드해두는 것이 보편화되었다. 그러나 이러한 방식은 결코 효율적이지 않다.
한편 많은 어플리케이션들에 있어서, 특히 비디오 게임에서는, 대용량 파일들을 패치(patch)하는 과정이 요구된다. 패치(patch)를 적용하기 위해서 파일 전체가 메모리에 로딩되어야 하기 때문에, 대용량 파일들을 위하여 차분 패치(patch)하는 과정은 어쩌면 느릴 수 있다. 예를 들어, 1 기가의 파일을 저장부에서 메모리로 판독하는 과정은 패치(patch)를 적용시키기 전에 이미 1 분 이상의 시간이 소모된다.
이러한 두 개의 패치(patch)하는 종래 방식들은 대역폭 비용으로 인한 문제를 제시할 수 있다. 특히 다운로드 되어야 할 대체 파일(replacement file)이 저장부(115)에서 사용 가능한 공간의 상당 부분을 차지하고 있을 때 문제가 심각해진다. 예를 들어 500 메가바이트의 패치된(patched) 파일을 다운로드 하는 과정은 20 기가바이트의 하드 드라이브에서 상당 부분을 차지할 수 있다.
나아가 여러 개의 대용량 파일들이 극소량의 데이터가 대체되는 것을 요구할 때 곤란한 경우가 발생할 수 있다. 예를 들어 어플리케이션은 파일들 각각의 시작 지점의 16 바이트 ID에 있는 버그(bug)를 지닌 여러 파일들을 가지고 있을 수 있다. 그러나 패치(patch) 과정은 파일 크기 레벨에서만 수행되기 때문에 파일을 대체함으로써 패치(patch)를 적용한다는 것은 어플리케이션에 있는 모든 단일의 파일을 다운로드하고 대체한다는 것을 의미한다. 이는 파일들이 수 기가바이트의 데이터까지 축적되어 있는 경우에는 비현실적이다. 만약 파일들이 전통적인 차분 패치(patch)로 패치(patch)되었다 하여도, 패치(patch)를 적용하기 위해서는 모든 파일들이 다른 곳으로 카피되어야만 한다.
이러한 문제점들을 극복하기 위하여, 이진 차 패치(patch)는 전통 방식으로 생성되고 다운로드될 수 있다. 그러나 패치(patch)를 오프라인 상에서 적용하는 대신, 런타임에서(예. 어플리케이션이 실행되는 동안 어플리케이션에서의 I/O 요청을 이행하는 과정의 일부로) 적용할 수 있다. 상술된 즉각적인 청킹 과정은 이점을 제공하기도 하지만, 이러한 이진 차 패치를 런타임 동안 구현하기 위해서는 필요하지 않다.
패치(patch)들은 트리 구조에서 비교적 이른 과정에서 적용될 수 있다. 예를 들어, 인커밍 I/O 요청을 초기 처리하는 과정의 일부는 요청에 열거된 파일들을 위한 차분 패치(patch)가 있는 지 판단하기 위해 패치 표(patch table)를 체크하는 과정을 포함할 수 있다. 이는 상술된, 디아카이버가 TOC를 검색(lookup)하는 과정과 비슷한 과정이다. RAM에 저장되어 있을 수 있는 패치 표(patch table)는 패치(patch)들을 어떻게 어디에서 적용해야하는지 파악하기 위한, FIOS(101)에 의해 요구되는 정보를 포함한다.
상기의 상세한 설명은 본 발명의 바람직한 실시예의 온전한 설명이지만, 다른 균등물과 변형들이 사용될 수 있다. 그러므로, 본 발명의 범위는 상기 설명을 참조하여 판단되지 말아야 하며, 대신, 첨부된 청구항들과 그 균등물들의 모든 범위를 함께 참조해서 판단되어야한다. 본 명세서에 서술된 어떠한 기술적 특징도, 본 명세서에 서술된 다른 어떠한 기술적 특징과 바람직하게든 아니든 결합될 수 있다. 첨부된 청구항들에 "~을 위한 수단(means for)"의 기재가 명시적으로 사용되지 않은 이상, 수단 또는 과정으로 해석되어서는 안 된다.
본 발명이 특정 바람직한 버전의 실시예를 참조하여 상당히 상세하게 서술되었지만, 다른 버전의 실시예들도 가능하다. 그러므로 첨부된 청구항들의 사상과 범위는 본 명세서에 포함된 바람직한 실시예들로 한정되어서는 안된다.
본 명세서와 함께 제출되고 공개된, 모든 논문과 문서들을 본 명세서에 기입되었고, 이러한 모든 논문 및 문서들의 내용들은 본 명세서에 참조되었다.
본 명세서에 개시된 모든 기술적 구성들(첨부된 청구항, 요약 및 도면들 포함)은 목적이 다른 것으로 명시적으로 표현하지 않는 이상, 동일하거나 동등하거나 유사한 목적을 가진 대체 선택적 구성들로 대체될 수 있다. 그러므로 개시된 기술적 구성들 각각은 단지 동등하거나 유사한 기술적 구성들의 일반적인 시리즈 중 하나의 예일 뿐이다.

Claims (45)

  1. 프로세서, 메모리 및 하나 이상의 미디어 또는 저장 장치들을 구비한 시스템에 있어서, 상기 하나 이상의 미디어(media) 또는 저장 장치들과 왕복적으로 입출력(input or output; I/O)하는 과정을 처리하기 위한 방법으로,
    a) 상기 하나 이상의 미디어 또는 저장 장치들로 데이터를 송수신하기 위해 상기 프로세서에서 실행되는 어플리케이션(application)으로부터의 인커밍(incoming) I/O 요청을 수신하는 과정과,
    b) 상기 프로세서에 의해 실행가능하고, 상기 메모리에 내장된 인스트럭션들(instructions)을 포함하고, 상기 I/O 요청과 연관된 하나 이상의 처리 과정의 계층(layer of processing)들을 지정하는 트리 구조(tree structure)를 생성하는 과정과,
    c) 청크들 각각의 위치 및 다른 처리 과정의 계층들의 청크들 사이 데이터 종속성들을 판단하여, 상기 트리 구조에 있는 상기 인스트럭션들을 처리 순서로 분류하는 과정과,
    d) 상기 메모리에 내장된 스케줄에 하나 이상의 인스트럭션들을 삽입하는 과정과,
    e) 상기 프로세서로 상기 스케줄에 따라 상기 삽입된 하나 이상의 인스트럭션들을 포함하는 상기 인스트럭션들을 실행하여, 상기 I/O 요청을 수행(service)하는 과정을 포함하고,
    상기 b) 과정에서, 상기 인스트럭션들은,
    상기 하나 이상의 처리 과정의 계층들 각각에서, 상기 I/O 요청에 있는 상기 데이터를 하나 이상의 청크들로 나누고,
    상기 e) 과정에서, 상기 실행은,
    상기 메모리에 내장된 상기 트리 구조와 연관된 상기 처리 순서에 따라 상기 프로세서에 의해 수행되고,
    하나 이상의 상기 계층들에 있는 인스트럭션들 각각은,
    상기 하나 이상의 계층들의 상기 트리구조에 있어서의 이전 계층에 있는 하나 이상의 대응 인스트럭션들에 연관된 데이터 종속성(data dependency)을 가지고,
    특정 인스트럭션의 상기 데이터 종속성은,
    상기 트리구조에 있어서의 상기 하나 이상의 계층들의 이전 계층에 있는 대응하는 하나 이상의 종속된 인스트럭션들이 실행된 후에만 실행되도록 하고,
    상기 스케줄 내에 있는 상기 삽입된 하나 이상의 인스트럭션들의 위치는,
    적어도 부분적으로 상기 처리 순서에 의존하는 것을 특징으로 하는 방법.
  2. 제 1항에 있어서,
    특정 처리 과정의 계층과 연관된 상기 청크들은,
    다른 처리 과정의 계층과 연관된 상기 청크들과 다른 크기를 가진 것을 특징으로 하는 방법.
  3. 제 1항에 있어서,
    상기 e) 과정은,
    종속성을 가진 특정 인스트럭션을 실행하기 전에, 이전 계층에 있는 종속된 인스트럭션의 실행이 완료되었는지 파악하는 과정을 포함하는 것을 특징으로 하는 방법.
  4. 제 1항에 있어서,
    상기 트리 구조는 최하위(lowermost) 계층을 포함하고,
    상기 최하위 계층의 하나 이상의 인스트럭션들은 상기 최하위 계층에 있는 다른 인스트럭션에 연관된 데이터 종속성을 가지고,
    상기 최하위 계층에 있는 특정 인스트럭션의 상기 데이터 종속성은 상기 최하위 계층에 있는 대응하는 하나 이상의 종속된 인스트럭션들의 실행 과정 후에만 상기 특정 인스트럭션이 실행되도록 하는 것을 특징으로 하는 방법.
  5. 제 1항에 있어서,
    상기 e) 과정은,
    처리 과정의 공통된 계층에서의 두 개 이상의 인스트럭션들을 병렬적으로 실행하는 과정을 포함하는 것을 특징으로 하는 방법.
  6. 제 1항에 있어서,
    상기 e) 과정은,
    처리 과정의 두 개 이상의 다른 계층들로부터의 두 개 이상의 인스트럭션들을 병렬적으로 실행하는 과정을 포함하는 것을 특징으로 하는 방법.
  7. 제 1항에 있어서,
    상기 e) 과정은,
    상기 트리 구조의 상기 인스트럭션들의 실행 과정 중 하나 이상의 다른 I/O 요청들로부터의 하나 이상의 인스트럭션들의 실행 과정을 상기 프로세서로 인터리브(interleave) 하는 과정을 포함하는 것을 특징으로 하는 방법.
  8. 제 7항에 있어서,
    상기 e) 과정은,
    상기 하나 이상의 다른 I/O 요청들로부터의 상기 삽입된 하나 이상의 인스트럭션들을 포함하는 상기 인스트럭션들을 상기 트리 구조의 하나 이상의 인스트럭션들과 병렬적으로 실행하는 과정을 포함하는 것을 특징으로 하는 방법.
  9. 제 1항에 있어서,
    처리 과정의 상기 하나 이상의 계층들은,
    디아카이빙(de-archiving) 또는 아카이빙(archiving) 계층을 포함하는 것을 특징으로 하는 방법.
  10. 제 1항에 있어서,
    처리 과정의 상기 하나 이상의 계층들은,
    복호화 또는 부호화 계층을 포함하는 것을 특징으로 하는 방법.
  11. 제 1항에 있어서,
    처리 과정의 상기 하나 이상의 계층들은,
    복원화 또는 압축 계층을 포함하는 것을 특징으로 하는 방법.
  12. 제 1항에 있어서,
    상기 d) 과정에서 상기 스케줄 내에 있는 상기 인커밍 I/O 요청의 삽입 과정은,
    상기 I/O 요청과 연관된 우선순위(priority) 제약(constraint)에 더 의존하는 것을 특징으로 하는 방법.
  13. 제 1항에 있어서,
    상기 d) 과정에서 상기 스케줄 내에 있는 상기 인커밍 I/O 요청의 삽입 과정은,
    상기 I/O 요청과 연관된 기한 제약에 더 의존하는 것을 특징으로 하는 방법.
  14. 제1항에 있어서,
    상기 e) 과정은,
    상기 스케줄에 삽입되기 전에 두 개 이상의 I/O 요청들과 연관된 상기 트리 구조들이 미리 설정된 오버랩(overlap) 입계 값을 충족시킬 때, 상기 두 개 이상의 I/O 요청들을 인터리브하는 과정을 포함하는 것을 특징으로 하는 방법.
  15. 제 1항에 있어서,
    상기 e) 과정은,
    런타임(runtime) 동안에 하나 이상의 파일들에 미분 패치(differential patch)를 적용하는 과정을 포함하는 것을 특징으로 하는 방법.
  16. 입출력(I/O)하는 과정을 처리하는 시스템으로,
    프로세서와,
    상기 프로세서에 연결된 메모리와,
    상기 프로세서에 연결된 하나 이상의 미디어 또는 저장 장치들과, 및
    상기 메모리에 내장된 프로세서 실행가능하며, 실행 시, 상기 하나 이상의 미디어 또는 저장 장치들과 왕복적으로 I/O하는 과정을 처리하는 방법을 구현하도록 설정된 인스트럭션들의 세트를 포함하며,
    상기 방법은,
    a) 상기 하나 이상의 미디어 또는 저장 장치들로 데이터를 송수신하기 위해 상기 프로세서에서 실행되는 어플리케이션(application)으로부터의 인커밍(incoming) I/O 요청을 수신하는 과정과,
    b) 상기 프로세서에 의해 실행가능하고, 상기 메모리에 내장된 인스트럭션들(instructions)을 포함하고, 상기 I/O 요청과 연관된 하나 이상의 처리 과정의 계층(layer of processing)들을 지정하는 트리 구조(tree structure)를 생성하는 과정과,
    c) 청크들 각각의 위치 및 다른 처리 과정의 계층들의 청크들 사이 데이터 종속성들을 판단하여, 상기 트리 구조에 있는 상기 인스트럭션들을 처리 순서로 분류하는 과정과,
    d) 상기 메모리에 내장된 스케줄에 하나 이상의 인스트럭션들을 삽입하는 과정과,
    e) 상기 프로세서로 상기 스케줄에 따라 상기 삽입된 하나 이상의 인스트럭션들을 포함하는 상기 인스트럭션들을 실행하여, 상기 I/O 요청을 수행(service)하는 과정을 포함하고,
    상기 b) 과정에서, 상기 인스트럭션들은,
    상기 하나 이상의 처리 과정의 계층들 각각에서, 상기 I/O 요청에 있는 상기 데이터를 하나 이상의 청크들로 나누고,
    상기 e) 과정에서, 상기 실행은,
    상기 메모리에 내장된 상기 트리 구조와 연관된 상기 처리 순서에 따라 상기 프로세서에 의해 수행되고,
    하나 이상의 상기 계층들에 있는 인스트럭션들 각각은,
    상기 하나 이상의 계층들의 상기 트리구조에 있어서의 이전 계층에 있는 하나 이상의 대응 인스트럭션들에 연관된 데이터 종속성(data dependency)을 가지고,
    특정 인스트럭션의 상기 데이터 종속성은,
    상기 트리구조에 있어서의 상기 하나 이상의 계층들의 이전 계층에 있는 대응하는 하나 이상의 종속된 인스트럭션들이 실행된 후에만 실행되도록 하고,
    상기 스케줄 내에 있는 상기 삽입된 하나 이상의 인스트럭션들의 위치는,
    적어도 부분적으로 상기 처리 순서에 의존하는 것을 특징으로 하는 시스템.
  17. 제 16항에 있어서,
    특정 처리 과정의 계층과 연관된 상기 청크들은,
    다른 처리 과정의 계층과 연관된 상기 청크들과 다른 크기를 가진 것을 특징으로 하는 시스템.
  18. 제 16항에 있어서,
    상기 e) 과정은,
    종속성을 가진 특정 인스트럭션을 실행하기 전에, 이전 계층에 있는 종속된 인스트럭션의 실행이 완료되었는지 파악하는 과정을 포함하는 것을 특징으로 하는 시스템.
  19. 제 16항에 있어서,
    상기 트리 구조는 최하위(lowermost) 계층을 포함하고,
    상기 최하위 계층의 하나 이상의 인스트럭션들은 상기 최하위 계층에 있는 다른 인스트럭션에 연관된 데이터 종속성을 가지고,
    상기 최하위 계층에 있는 특정 인스트럭션의 상기 데이터 종속성은 상기 최하위 계층에 있는 대응하는 하나 이상의 종속된 인스트럭션들의 실행 과정 후에만 상기 특정 인스트럭션이 실행되도록 하는 것을 특징으로 하는 시스템.
  20. 제 16항에 있어서,
    상기 e) 과정은,
    처리 과정의 공통된 계층에서의 두 개 이상의 인스트럭션들을 병렬적으로 실행하는 과정을 포함하는 것을 특징으로 하는 시스템.
  21. 제 16항에 있어서,
    상기 e) 과정은,
    처리 과정의 두 개 이상의 다른 계층들로부터의 두 개 이상의 인스트럭션들을 병렬적으로 실행하는 과정을 포함하는 것을 특징으로 하는 시스템.
  22. 제 16항에 있어서,
    상기 e) 과정은,
    상기 트리 구조의 상기 인스트럭션들의 실행 과정 중 하나 이상의 다른 I/O 요청들로부터의 하나 이상의 인스트럭션들의 실행 과정을 상기 프로세서로 인터리브(interleave) 하는 과정을 포함하는 것을 특징으로 하는 시스템.
  23. 제 22항에 있어서,
    상기 e) 과정은,
    상기 하나 이상의 다른 I/O 요청들로부터의 상기 삽입된 하나 이상의 인스트럭션들을 포함하는 상기 인스트럭션들을 상기 트리 구조의 하나 이상의 인스트럭션들과 병렬적으로 실행하는 과정을 포함하는 것을 특징으로 하는 시스템.
  24. 제 16항에 있어서,
    처리 과정의 상기 하나 이상의 계층들은,
    디아카이빙(de-archiving) 또는 아카이빙(archiving) 계층을 포함하는 것을 특징으로 하는 시스템.
  25. 제 16항에 있어서,
    처리 과정의 상기 하나 이상의 계층들은,
    복호화 또는 부호화 계층을 포함하는 것을 특징으로 하는 시스템.
  26. 제 16항에 있어서,
    처리 과정의 상기 하나 이상의 계층들은,
    복원화 또는 압축 계층을 포함하는 것을 특징으로 하는 시스템.
  27. 제 16항에 있어서,
    상기 d) 과정에서 상기 스케줄 내에 있는 상기 인커밍 I/O 요청의 삽입 과정은,
    상기 I/O 요청과 연관된 우선순위(priority) 제약(constraint)에 더 의존하는 것을 특징으로 하는 시스템.
  28. 제 16항에 있어서,
    상기 d) 과정에서 상기 스케줄 내에 있는 상기 인커밍 I/O 요청의 삽입 과정은,
    상기 I/O 요청과 연관된 기한 제약에 더 의존하는 것을 특징으로 하는 시스템.
  29. 제 16항에 있어서,
    상기 e) 과정은,
    상기 스케줄에 삽입되기 전에 두 개 이상의 I/O 요청들과 연관된 상기 트리 구조들이 미리 설정된 오버랩(overlap) 입계 값을 충족시킬 때, 상기 두 개 이상의 I/O 요청들을 인터리브하는 과정을 포함하는 것을 특징으로 하는 시스템.
  30. 제 16항에 있어서,
    상기 e) 과정은,
    런타임(runtime) 동안에 하나 이상의 파일들에 미분 패치(differential patch)를 적용하는 과정을 포함하는 것을 특징으로 하는 시스템.
  31. 내장된 컴퓨터 판독가능한 프로그램 코드를 가진 컴퓨터 판독가능한 매체를 포함하는 컴퓨팅 장치로,
    상기 컴퓨터 판독가능한 프로그램 코드는,
    컴퓨터 실행가능하며, 실행 시, 하나 이상의 미디어 또는 저장 장치들과 왕복적으로 I/O 과정을 처리하는 인스트럭션들을 포함하고,
    상기 프로그램 코드는,
    a) 상기 하나 이상의 미디어 또는 저장 장치들로 데이터를 송수신하기 위해 프로세서에서 실행되는 어플리케이션(application)으로부터의 인커밍(incoming) I/O 요청을 수신하는 컴퓨터 실행가능한 프로그램 코드 수단과,
    b) 상기 프로세서에 의해 실행가능하고, 메모리에 내장된 인스트럭션들(instructions)을 포함하고, 상기 I/O 요청과 연관된 하나 이상의 처리 과정의 계층(layer of processing)들을 지정하는 트리 구조(tree structure)를 생성하는 컴퓨터 실행가능한 프로그램 코드 수단과,
    c) 청크들 각각의 위치 및 다른 처리 과정의 계층들의 청크들 사이 데이터 종속성들을 판단하여, 상기 트리 구조에 있는 상기 인스트럭션들을 처리 순서로 분류하는 컴퓨터 판독가능한 프로그램 코드 수단과,
    d) 상기 메모리에 내장된 스케줄에 하나 이상의 인스트럭션들을 삽입하는 컴퓨터 판독가능한 프로그램 코드 수단과,
    e) 상기 프로세서로 상기 스케줄에 따라 상기 삽입된 하나 이상의 인스트럭션들을 포함하는 상기 인스트럭션들을 실행하여, 상기 I/O 요청을 수행(service)하는 컴퓨터 판독가능한 프로그램 코드 수단을 포함하고,
    상기 b) 컴퓨터 실행가능한 프로그램 코드 수단에서, 상기 인스트럭션들은,
    상기 하나 이상의 처리 과정의 계층들 각각에서, 상기 I/O 요청에 있는 상기 데이터를 하나 이상의 청크들로 나누고,
    상기 e) 컴퓨터 판독가능한 프로그램 코드 수단에서, 상기 실행은,
    상기 메모리에 내장된 상기 트리 구조와 연관된 상기 처리 순서에 따라 상기 프로세서에 의해 수행되고,
    하나 이상의 상기 계층들에 있는 인스트럭션들 각각은,
    상기 하나 이상의 계층들의 상기 트리구조에 있어서의 이전 계층에 있는 하나 이상의 대응 인스트럭션들에 연관된 데이터 종속성(data dependency)을 가지고,
    특정 인스트럭션의 상기 데이터 종속성은,
    상기 트리구조에 있어서의 상기 하나 이상의 계층들의 이전 계층에 있는 대응하는 하나 이상의 종속된 인스트럭션들이 실행된 후에만 실행되도록 하고,
    상기 스케줄 내에 있는 상기 삽입된 하나 이상의 인스트럭션들의 위치는,
    적어도 부분적으로 상기 처리 순서에 의존하는 것을 특징으로 하는 컴퓨팅 장치.
  32. 제 31항에 있어서,
    특정 처리 과정의 계층과 연관된 상기 청크들은,
    다른 처리 과정의 계층과 연관된 상기 청크들과 다른 크기를 가진 것을 특징으로 하는 컴퓨팅 장치.
  33. 제 31항에 있어서,
    상기 e) 컴퓨터 판독가능한 프로그램 코드 수단은,
    종속성을 가진 특정 인스트럭션을 실행하기 전에, 이전 계층에 있는 종속된 인스트럭션의 실행이 완료되었는지 파악하기 위한 컴퓨터 판독가능한 프로그램코드 수단을 포함하는 것을 특징으로 하는 컴퓨팅 장치.
  34. 제 31항에 있어서,
    상기 트리 구조는 최하위(lowermost) 계층을 포함하고,
    상기 최하위 계층의 하나 이상의 인스트럭션들은 상기 최하위 계층에 있는 다른 인스트럭션에 연관된 데이터 종속성을 가지고,
    상기 최하위 계층에 있는 특정 인스트럭션의 상기 데이터 종속성은 상기 최하위 계층에 있는 대응하는 하나 이상의 종속된 인스트럭션들의 실행 과정 후에만 상기 특정 인스트럭션이 실행되도록 하는 것을 특징으로 하는 컴퓨팅 장치.
  35. 제 31항에 있어서,
    상기 e) 컴퓨터 판독가능한 프로그램 코드 수단은,
    처리 과정의 공통된 계층에서의 두 개 이상의 인스트럭션들을 병렬적으로 실행하기 위한 컴퓨터 판독가능한 프로그램 코드 수단을 포함하는 것을 특징으로 하는 컴퓨팅 장치.
  36. 제 31항에 있어서,
    상기 e) 컴퓨터 판독가능한 프로그램 코드 수단은,
    처리 과정의 두 개 이상의 다른 계층들로부터의 두 개 이상의 인스트럭션들을 병렬적으로 실행하기 위한 컴퓨터 판독가능한 프로그램 코드 수단을 포함하는 것을 특징으로 하는 컴퓨팅 장치.
  37. 제 31항에 있어서,
    상기 e) 컴퓨터 판독가능한 프로그램 코드 수단은,
    상기 트리 구조의 상기 인스트럭션들의 실행 과정 중 하나 이상의 다른 I/O 요청들로부터의 하나 이상의 인스트럭션들의 실행 과정을 상기 프로세서로 인터리브(interleave) 하기 위한 컴퓨터 판독가능한 프로그램 코드를 포함하는 것을 특징으로 하는 컴퓨팅 장치.
  38. 제 37항에 있어서,
    상기 e) 컴퓨터 판독가능한 프로그램 코드 수단은,
    상기 하나 이상의 다른 I/O 요청들로부터의 상기 삽입된 하나 이상의 인스트럭션들을 포함하는 상기 인스트럭션들을 상기 트리 구조의 하나 이상의 인스트럭션들과 병렬적으로 실행하하기 위한 컴퓨터 판독가능한 프로그램 코드를 포함하는 것을 특징으로 하는 컴퓨팅 장치.
  39. 제 31항에 있어서,
    처리 과정의 상기 하나 이상의 계층들은,
    디아카이빙(de-archiving) 또는 아카이빙(archiving) 계층을 포함하는 것을 특징으로 하는 컴퓨팅 장치.
  40. 제 31항에 있어서,
    처리 과정의 상기 하나 이상의 계층들은,
    복호화 또는 부호화 계층을 포함하는 것을 특징으로 하는 컴퓨팅 장치.
  41. 제 31항에 있어서,
    처리 과정의 상기 하나 이상의 계층들은,
    복원화 또는 압축 계층을 포함하는 것을 특징으로 하는 컴퓨팅 장치.
  42. 제 31항에 있어서,
    상기 d) 컴퓨터 판독가능한 프로그램 코드 수단에서 상기 스케줄 내에 있는 상기 인커밍 I/O 요청의 삽입 컴퓨터 판독가능한 프로그램 코드 수단은,
    상기 I/O 요청과 연관된 우선순위(priority) 제약(constraint)에 더 의존하는 것을 특징으로 하는 컴퓨팅 장치.
  43. 제 31항에 있어서,
    상기 d) 과정에서 상기 스케줄 내에 있는 상기 인커밍 I/O 요청의 삽입 컴퓨터 판독가능한 프로그램 코드 수단은,
    상기 I/O 요청과 연관된 기한 제약에 더 의존하는 것을 특징으로 하는 컴퓨팅 장치.
  44. 제 31항에 있어서,
    상기 e) 컴퓨터 판독가능한 프로그램 코드 수단은,
    상기 스케줄에 삽입되기 전에 두 개 이상의 I/O 요청들과 연관된 상기 트리 구조들이 미리 설정된 오버랩(overlap) 입계 값을 충족시킬 때, 상기 두 개 이상의 I/O 요청들을 인터리브하기 위한 컴퓨터 판독가능한 프로그램 코드를 포함하는 것을 특징으로 하는 컴퓨팅 장치.
  45. 제 31항에 있어서,
    상기 e) 컴퓨터 판독가능한 프로그램 코드 수단은,
    런타임(runtime) 동안에 하나 이상의 파일들에 미분 패치(differential patch)를 적용하기 위한 컴퓨터 판독가능한 프로그램 코드를 포함하는 것을 특징으로 하는 컴퓨팅 장치.
KR1020107026222A 2009-10-26 2010-10-14 데이터 즉시 청킹을 사용하여 파일 입출력을 스케줄 하는 방법 KR101188472B1 (ko)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US25501309P 2009-10-26 2009-10-26
US61/255,013 2009-10-26
US12/902,768 US8412856B2 (en) 2009-10-26 2010-10-12 File input/output scheduler using immediate data chunking
US12/902,768 2010-10-12
PCT/US2010/052698 WO2011053463A1 (en) 2009-10-26 2010-10-14 File input/output scheduler using immediate data chunking

Publications (2)

Publication Number Publication Date
KR20110074489A KR20110074489A (ko) 2011-06-30
KR101188472B1 true KR101188472B1 (ko) 2012-10-10

Family

ID=43899281

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020107026222A KR101188472B1 (ko) 2009-10-26 2010-10-14 데이터 즉시 청킹을 사용하여 파일 입출력을 스케줄 하는 방법

Country Status (7)

Country Link
US (1) US8412856B2 (ko)
EP (1) EP2353079B1 (ko)
JP (1) JP5292473B2 (ko)
KR (1) KR101188472B1 (ko)
CN (2) CN102171647B (ko)
BR (1) BRPI1001274B1 (ko)
WO (1) WO2011053463A1 (ko)

Families Citing this family (92)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9838450B2 (en) * 2010-06-30 2017-12-05 Brightcove, Inc. Dynamic chunking for delivery instances
US9378560B2 (en) * 2011-06-17 2016-06-28 Advanced Micro Devices, Inc. Real time on-chip texture decompression using shader processors
US8909764B2 (en) * 2011-07-28 2014-12-09 Xyratex Technology Limited Data communication method and apparatus
WO2013033731A1 (en) * 2011-09-02 2013-03-07 Lam Vu Systems and methods for processing software application metadata associated with a software application
US8712963B1 (en) 2011-12-22 2014-04-29 Emc Corporation Method and apparatus for content-aware resizing of data chunks for replication
US8639669B1 (en) * 2011-12-22 2014-01-28 Emc Corporation Method and apparatus for determining optimal chunk sizes of a deduplicated storage system
WO2013137886A1 (en) * 2012-03-15 2013-09-19 Hewlett-Packard Development Company, L.P. Two-level chunking for data analytics
CN102707966B (zh) * 2012-04-12 2014-09-03 腾讯科技（深圳）有限公司 加速操作系统启动的方法及装置、预取信息生成方法及装置和终端
US9703482B2 (en) * 2012-06-29 2017-07-11 Vmware, Inc. Filter appliance for object-based storage system
US10127081B2 (en) * 2012-08-30 2018-11-13 International Business Machines Corporation Efficient resource management in a virtualized computing environment
CN103729142B (zh) * 2012-10-10 2016-12-21 华为技术有限公司 内存数据的推送方法及装置
WO2014203029A1 (en) * 2013-06-17 2014-12-24 Freescale Semiconductor, Inc. Efficient scheduling in asynchronous contention-based system
US9819766B1 (en) 2014-07-30 2017-11-14 Google Llc System and method for improving infrastructure to infrastructure communications
US9715402B2 (en) 2014-09-30 2017-07-25 Amazon Technologies, Inc. Dynamic code deployment and versioning
US9678773B1 (en) 2014-09-30 2017-06-13 Amazon Technologies, Inc. Low latency computational capacity provisioning
US9323556B2 (en) 2014-09-30 2016-04-26 Amazon Technologies, Inc. Programmatic event detection and message generation for requests to execute program code
US9146764B1 (en) 2014-09-30 2015-09-29 Amazon Technologies, Inc. Processing event messages for user requests to execute program code
US10048974B1 (en) 2014-09-30 2018-08-14 Amazon Technologies, Inc. Message-based computation request scheduling
US9830193B1 (en) 2014-09-30 2017-11-28 Amazon Technologies, Inc. Automatic management of low latency computational capacity
US9600312B2 (en) 2014-09-30 2017-03-21 Amazon Technologies, Inc. Threading as a service
US9413626B2 (en) 2014-12-05 2016-08-09 Amazon Technologies, Inc. Automatic management of resource sizing
US9524249B2 (en) * 2014-12-23 2016-12-20 Intel Corporation Memory encryption engine integration
US9588790B1 (en) 2015-02-04 2017-03-07 Amazon Technologies, Inc. Stateful virtual compute system
US9733967B2 (en) 2015-02-04 2017-08-15 Amazon Technologies, Inc. Security protocols for low latency execution of program code
CN104699466B (zh) * 2015-03-26 2017-07-18 中国人民解放军国防科学技术大学 一种面向vliw体系结构的多元启发式指令选择方法
US9930103B2 (en) 2015-04-08 2018-03-27 Amazon Technologies, Inc. Endpoint management system providing an application programming interface proxy service
US9785476B2 (en) 2015-04-08 2017-10-10 Amazon Technologies, Inc. Endpoint management system and virtual compute system
US10462218B1 (en) 2015-07-15 2019-10-29 Google Llc System and method for sending proposals within a distributed state machine replication system
US10754701B1 (en) 2015-12-16 2020-08-25 Amazon Technologies, Inc. Executing user-defined code in response to determining that resources expected to be utilized comply with resource restrictions
US9811434B1 (en) 2015-12-16 2017-11-07 Amazon Technologies, Inc. Predictive management of on-demand code execution
US10067801B1 (en) 2015-12-21 2018-09-04 Amazon Technologies, Inc. Acquisition and maintenance of compute capacity
US9910713B2 (en) 2015-12-21 2018-03-06 Amazon Technologies, Inc. Code execution request routing
CN107239328B (zh) * 2016-03-29 2020-06-09 上海普兰金融服务有限公司 任务分配方法及装置
US11132213B1 (en) 2016-03-30 2021-09-28 Amazon Technologies, Inc. Dependency-based process of pre-existing data sets at an on demand code execution environment
US10891145B2 (en) 2016-03-30 2021-01-12 Amazon Technologies, Inc. Processing pre-existing data sets at an on demand code execution environment
US10282229B2 (en) * 2016-06-28 2019-05-07 Amazon Technologies, Inc. Asynchronous task management in an on-demand network code execution environment
US10102040B2 (en) 2016-06-29 2018-10-16 Amazon Technologies, Inc Adjusting variable limit on concurrent code executions
US10277708B2 (en) 2016-06-30 2019-04-30 Amazon Technologies, Inc. On-demand network code execution with cross-account aliases
US10203990B2 (en) 2016-06-30 2019-02-12 Amazon Technologies, Inc. On-demand network code execution with cross-account aliases
US10884787B1 (en) 2016-09-23 2021-01-05 Amazon Technologies, Inc. Execution guarantees in an on-demand network code execution system
US10061613B1 (en) 2016-09-23 2018-08-28 Amazon Technologies, Inc. Idempotent task execution in on-demand network code execution systems
US11119813B1 (en) 2016-09-30 2021-09-14 Amazon Technologies, Inc. Mapreduce implementation using an on-demand network code execution system
US10564946B1 (en) 2017-12-13 2020-02-18 Amazon Technologies, Inc. Dependency handling in an on-demand network code execution system
US10831898B1 (en) 2018-02-05 2020-11-10 Amazon Technologies, Inc. Detecting privilege escalations in code including cross-service calls
US10733085B1 (en) 2018-02-05 2020-08-04 Amazon Technologies, Inc. Detecting impedance mismatches due to cross-service calls
US10353678B1 (en) 2018-02-05 2019-07-16 Amazon Technologies, Inc. Detecting code characteristic alterations due to cross-service calls
US10725752B1 (en) 2018-02-13 2020-07-28 Amazon Technologies, Inc. Dependency handling in an on-demand network code execution system
US10776091B1 (en) 2018-02-26 2020-09-15 Amazon Technologies, Inc. Logging endpoint in an on-demand code execution system
US10817331B2 (en) 2018-06-25 2020-10-27 Amazon Technologies, Inc. Execution of auxiliary functions in an on-demand network code execution system
US10853115B2 (en) 2018-06-25 2020-12-01 Amazon Technologies, Inc. Execution of auxiliary functions in an on-demand network code execution system
US10649749B1 (en) 2018-06-26 2020-05-12 Amazon Technologies, Inc. Cross-environment application of tracing information for improved code execution
US11146569B1 (en) 2018-06-28 2021-10-12 Amazon Technologies, Inc. Escalation-resistant secure network services using request-scoped authentication information
US10949237B2 (en) 2018-06-29 2021-03-16 Amazon Technologies, Inc. Operating system customization in an on-demand network code execution system
US11099870B1 (en) 2018-07-25 2021-08-24 Amazon Technologies, Inc. Reducing execution times in an on-demand network code execution system using saved machine states
CN110928575B (zh) * 2018-09-20 2022-04-29 上海登临科技有限公司 一种多设备同步控制系统和控制方法
US11099917B2 (en) 2018-09-27 2021-08-24 Amazon Technologies, Inc. Efficient state maintenance for execution environments in an on-demand code execution system
US11243953B2 (en) 2018-09-27 2022-02-08 Amazon Technologies, Inc. Mapreduce implementation in an on-demand network code execution system and stream data processing system
US11943093B1 (en) 2018-11-20 2024-03-26 Amazon Technologies, Inc. Network connection recovery after virtual machine transition in an on-demand network code execution system
US10884812B2 (en) 2018-12-13 2021-01-05 Amazon Technologies, Inc. Performance-based hardware emulation in an on-demand network code execution system
CN111526172B (zh) * 2019-02-03 2022-11-29 杭州登临瀚海科技有限公司 一种多设备管理方法和管理系统
US11010188B1 (en) 2019-02-05 2021-05-18 Amazon Technologies, Inc. Simulated data object storage using on-demand computation of data objects
US11861386B1 (en) 2019-03-22 2024-01-02 Amazon Technologies, Inc. Application gateways in an on-demand network code execution system
US11119809B1 (en) 2019-06-20 2021-09-14 Amazon Technologies, Inc. Virtualization-based transaction handling in an on-demand network code execution system
US11159528B2 (en) 2019-06-28 2021-10-26 Amazon Technologies, Inc. Authentication to network-services using hosted authentication information
US11115404B2 (en) 2019-06-28 2021-09-07 Amazon Technologies, Inc. Facilitating service connections in serverless code executions
US11190609B2 (en) 2019-06-28 2021-11-30 Amazon Technologies, Inc. Connection pooling for scalable network services
US11394761B1 (en) 2019-09-27 2022-07-19 Amazon Technologies, Inc. Execution of user-submitted code on a stream of data
US11055112B2 (en) 2019-09-27 2021-07-06 Amazon Technologies, Inc. Inserting executions of owner-specified code into input/output path of object storage service
US11550944B2 (en) 2019-09-27 2023-01-10 Amazon Technologies, Inc. Code execution environment customization system for object storage service
US11023311B2 (en) 2019-09-27 2021-06-01 Amazon Technologies, Inc. On-demand code execution in input path of data uploaded to storage service in multiple data portions
US11106477B2 (en) 2019-09-27 2021-08-31 Amazon Technologies, Inc. Execution of owner-specified code during input/output path to object storage service
US11386230B2 (en) 2019-09-27 2022-07-12 Amazon Technologies, Inc. On-demand code obfuscation of data in input path of object storage service
US11416628B2 (en) 2019-09-27 2022-08-16 Amazon Technologies, Inc. User-specific data manipulation system for object storage service based on user-submitted code
US10996961B2 (en) 2019-09-27 2021-05-04 Amazon Technologies, Inc. On-demand indexing of data in input path of object storage service
US11263220B2 (en) 2019-09-27 2022-03-01 Amazon Technologies, Inc. On-demand execution of object transformation code in output path of object storage service
US10908927B1 (en) 2019-09-27 2021-02-02 Amazon Technologies, Inc. On-demand execution of object filter code in output path of object storage service
US11656892B1 (en) 2019-09-27 2023-05-23 Amazon Technologies, Inc. Sequential execution of user-submitted code and native functions
US11250007B1 (en) 2019-09-27 2022-02-15 Amazon Technologies, Inc. On-demand execution of object combination code in output path of object storage service
US11360948B2 (en) 2019-09-27 2022-06-14 Amazon Technologies, Inc. Inserting owner-specified data processing pipelines into input/output path of object storage service
US11023416B2 (en) 2019-09-27 2021-06-01 Amazon Technologies, Inc. Data access control system for object storage service based on owner-defined code
US10942795B1 (en) 2019-11-27 2021-03-09 Amazon Technologies, Inc. Serverless call distribution to utilize reserved capacity without inhibiting scaling
US11119826B2 (en) 2019-11-27 2021-09-14 Amazon Technologies, Inc. Serverless call distribution to implement spillover while avoiding cold starts
US11714682B1 (en) 2020-03-03 2023-08-01 Amazon Technologies, Inc. Reclaiming computing resources in an on-demand code execution system
US11188391B1 (en) 2020-03-11 2021-11-30 Amazon Technologies, Inc. Allocating resources to on-demand code executions under scarcity conditions
CN111399912B (zh) * 2020-03-26 2022-11-22 超睿科技(长沙)有限公司 一种面向多周期指令的指令调度方法、系统及介质
US11775640B1 (en) 2020-03-30 2023-10-03 Amazon Technologies, Inc. Resource utilization-based malicious task detection in an on-demand code execution system
US11550713B1 (en) 2020-11-25 2023-01-10 Amazon Technologies, Inc. Garbage collection in distributed systems using life cycled storage roots
US11593270B1 (en) 2020-11-25 2023-02-28 Amazon Technologies, Inc. Fast distributed caching using erasure coded object parts
US11706221B1 (en) * 2021-05-25 2023-07-18 Two Six Labs, LLC Unidirectional atomic messaging
US11388210B1 (en) 2021-06-30 2022-07-12 Amazon Technologies, Inc. Streaming analytics using a serverless compute system
US11968280B1 (en) 2021-11-24 2024-04-23 Amazon Technologies, Inc. Controlling ingestion of streaming data to serverless function executions
CN114706798B (zh) * 2022-06-08 2022-08-12 四川省人工智能研究院(宜宾) 基于注意力机制的固态硬盘数据预取方法

Family Cites Families (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6549918B1 (en) * 1998-09-21 2003-04-15 Microsoft Corporation Dynamic information format conversion
JP3733784B2 (ja) * 1999-05-21 2006-01-11 株式会社日立製作所 パケット中継装置
JP2000357099A (ja) * 1999-06-15 2000-12-26 Hitachi Ltd ディスク入出力方法
US6804710B1 (en) * 2000-03-10 2004-10-12 Hitachi, Ltd. Configuration information management system, method, program, and program storage device
US7069555B1 (en) 2000-09-29 2006-06-27 Microsoft Corporation Super-region instruction scheduling and code generation for merging identical instruction into the ready-to-schedule instruction
JP4131514B2 (ja) * 2003-04-21 2008-08-13 インターナショナル・ビジネス・マシーンズ・コーポレーション ネットワークシステム、サーバ、データ処理方法及びプログラム
US7685254B2 (en) 2003-06-10 2010-03-23 Pandya Ashish A Runtime adaptable search processor
US7287133B2 (en) * 2004-08-24 2007-10-23 Symantec Operating Corporation Systems and methods for providing a modification history for a location within a data store
US7827362B2 (en) * 2004-08-24 2010-11-02 Symantec Corporation Systems, apparatus, and methods for processing I/O requests
US7730222B2 (en) * 2004-08-24 2010-06-01 Symantec Operating System Processing storage-related I/O requests using binary tree data structures
US7904428B2 (en) * 2003-09-23 2011-03-08 Symantec Corporation Methods and apparatus for recording write requests directed to a data store
US20050108414A1 (en) 2003-11-14 2005-05-19 Taylor Thomas M. System and method for transmitting data in computer systems using virtual streaming
US7472384B1 (en) 2003-12-02 2008-12-30 Swsoft Holdings, Ltd. System, method and computer program product for on-the-fly patching of executable code
JP4668794B2 (ja) * 2003-12-19 2011-04-13 パナソニック株式会社 記録デバイス制御装置
US7904192B2 (en) * 2004-01-14 2011-03-08 Agency For Science, Technology And Research Finite capacity scheduling using job prioritization and machine selection
JP4672282B2 (ja) 2004-05-07 2011-04-20 株式会社日立製作所 情報処理装置、及び情報処理装置の制御方法
US7676646B2 (en) * 2005-03-02 2010-03-09 Cisco Technology, Inc. Packet processor with wide register set architecture
JP4372043B2 (ja) * 2005-05-12 2009-11-25 株式会社ソニー・コンピュータエンタテインメント コマンド実行制御装置、コマンド実行指示装置およびコマンド実行制御方法
JP4611830B2 (ja) * 2005-07-22 2011-01-12 優 喜連川 データベース管理システム及び方法
US7376758B2 (en) * 2005-11-04 2008-05-20 Sun Microsystems, Inc. I/O dependency graphs
US7398329B2 (en) 2005-11-04 2008-07-08 Sun Microsystems, Inc. Pipelined I/O execution
JP4755487B2 (ja) * 2005-11-24 2011-08-24 株式会社日立製作所 データ読出しシステム、データ読出し装置およびデータ読出し方法
US7721009B2 (en) 2006-11-22 2010-05-18 International Business Machines Corporation Method for providing high performance scalable file I/O through persistent file domain and functional partitioning
JP4941034B2 (ja) * 2007-03-20 2012-05-30 富士通株式会社 アクセス制御装置およびアクセス制御方法
JP4071816B1 (ja) * 2007-03-22 2008-04-02 透 降矢 合成関係演算を利用したマルチオペレーション・プロセッシングを用いたデータベースのクエリー処理システム
JP2009199367A (ja) * 2008-02-21 2009-09-03 Nec Corp 計算機システム、ｉ／ｏスケジューラ及びｉ／ｏスケジューリング方法

Also Published As

Publication number Publication date
BRPI1001274A2 (pt) 2016-02-16
JP2012505490A (ja) 2012-03-01
CN103123595A (zh) 2013-05-29
EP2353079B1 (en) 2018-12-05
CN103123595B (zh) 2016-03-02
CN102171647A (zh) 2011-08-31
WO2011053463A1 (en) 2011-05-05
CN102171647B (zh) 2014-02-26
EP2353079A1 (en) 2011-08-10
BRPI1001274B1 (pt) 2020-02-04
US20110099204A1 (en) 2011-04-28
US8412856B2 (en) 2013-04-02
JP5292473B2 (ja) 2013-09-18
EP2353079A4 (en) 2017-02-15
KR20110074489A (ko) 2011-06-30

Similar Documents

Publication Publication Date Title
KR101188472B1 (ko) 데이터 즉시 청킹을 사용하여 파일 입출력을 스케줄 하는 방법
KR101238163B1 (ko) 파일 입출력 스케줄러
US10114865B2 (en) Tile cache
RU2673694C2 (ru) Измененное сжатие памяти
KR101034080B1 (ko) 균일한 비디오 디코딩 및 디스플레이
EP3008602B1 (en) Page-based compressed storage management
KR101979621B1 (ko) 다운로드 가능한 컨텐츠의 전송을 최적화하는 시스템 및 장치
US10073649B2 (en) Storing metadata
CN101930364B (zh) 用于产生多语言菜单的方法
US20100250864A1 (en) Method And Apparatus For Compressing And Decompressing Data
CN107533508B (zh) 用于减少压缩存储器时的存储器承诺用量的方法和系统
CN105247478B (zh) 用于存储命令的方法及相关装置
US20220004405A1 (en) 3D API Redirection for Virtual Desktop Infrastructure
KR20190020039A (ko) 가변 길이 코딩된 파일을 디코딩하는 방법 및 장치
US20220374395A1 (en) Hybrid file compression model
KR20080044872A (ko) 컴퓨터 상에서 정보 또는 데이터를 처리하기 위한 시스템및 방법
KR100848284B1 (ko) 소프트웨어 스트리밍을 제공하는 적재기 및 방법
US20100146198A1 (en) Optimal power usage in decoding a content stream stored in a secondary storage
TWI707235B (zh) 儲存裝置管理系統以及儲存裝置管理方法
TW200809597A (en) Method and system for device to request and operate an external buffer provided from the host
CN114157918A (zh) 一种媒体文件播放方法、装置、计算设备与可读存储介质

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
AMND Amendment
E601 Decision to refuse application
AMND Amendment
X701 Decision to grant (after re-examination)
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20150909

Year of fee payment: 4

FPAY Annual fee payment

Payment date: 20160909

Year of fee payment: 5

FPAY Annual fee payment

Payment date: 20170913

Year of fee payment: 6

FPAY Annual fee payment

Payment date: 20180906

Year of fee payment: 7