KR101238163B1 - 파일 입출력 스케줄러 - Google Patents

파일 입출력 스케줄러 Download PDF

Info

Publication number
KR101238163B1
KR101238163B1 KR1020107029818A KR20107029818A KR101238163B1 KR 101238163 B1 KR101238163 B1 KR 101238163B1 KR 1020107029818 A KR1020107029818 A KR 1020107029818A KR 20107029818 A KR20107029818 A KR 20107029818A KR 101238163 B1 KR101238163 B1 KR 101238163B1
Authority
KR
South Korea
Prior art keywords
request
incoming
data
media device
schedule
Prior art date
Application number
KR1020107029818A
Other languages
English (en)
Other versions
KR20110019763A (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 KR20110019763A publication Critical patent/KR20110019763A/ko
Application granted granted Critical
Publication of KR101238163B1 publication Critical patent/KR101238163B1/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/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/061—Improving I/O performance
    • G06F3/0611—Improving I/O performance in relation to response time
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0638—Organizing or formatting or addressing of data
    • G06F3/064—Management of blocks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0655—Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
    • G06F3/0659—Command handling arrangements, e.g. command buffers, queues, command scheduling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/0671—In-line storage system
    • G06F3/0673—Single storage device
    • G06F3/0674—Disk device
    • 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/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4812—Task transfer initiation or dispatching by interrupt, e.g. masked

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Human Computer Interaction (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Signal Processing For Digital Recording And Reproducing (AREA)

Abstract

미디어 장치로 왕복적으로 입출력(input/output; I/O) 과정을 처리하는 과정은 메모리, 메인 프로세서와 연계된 로컬 메모리를 구비한 보조 프로세서를 장착한 프로세서부 및 미디어 장치를 구비한 시스템에서 구현될 수 있다. 프로세서부에서 실행되는 어플리케이션으로부터 수신된 인커밍 I/O 요청은 스케줄에 따라 수행될 수 있다. I/O 처리 과정을 구현하도록 설정된 프로세서 실행가능한 인스트럭션들의 일군은 미디어 필터 계층들을 포함할 수 있다. 선택적으로 I/O 처리 과정은 메인 프로세서에서 실행되는 어플리케이션으로부터의 인커밍 I/O 요청을 수신하는 과정과, 메인 메모리에 내장된 스케줄에 요청을 삽입하는 과정과, 및 스케줄 및 하나 이상의 필터들, 그 중 적어도 하나는 보조 프로세서에 의해 구현되는 필터에 따라 요청을 구현하는 과정을 포함한다.

Description

파일 입출력 스케줄러 {File input/output scheduler}
본 발명의 실시예들은 컴퓨터 게임 및 그와 관련된 어플리케이션들에 관한 발명이며, 특히 컴퓨터 게임 및 그와 관련된 어플리케이션들의 파일 입출력(input/output; I/O)을 관리하는 방법에 관한 발명이다.
본 출원은 2008년 5월 30일에 출원된 미국 특허 출원 12/130,892를 기초로 우선권 주장을 하는 출원이다. 이 우선권 주장 기초 출원의 기재 내용 전부는 본 명세서에 참조로서 기재되어 있는 것으로 한다.
비디오 게임과 같은 많은 소프트웨어 어플리케이션들은, 어플리케이션 내 접속이 더 효율적이도록 하고 또한 그 신뢰도(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)된다. 이와 같은 구성요소들은 데이터를 처리하기 위해 데이터의 연속적인 흐름을 필요로 하지 않지만, 청크들의 전달 시점은 종종 중요하다. 어플리케이션이 데이터를 필요로 할 때 데이터를 수신하지 못 하면 성능이 저하될 수 있다.
비디오 게임들은 주로 상당량의 입출력 과정을 수행한다. 게임 이벤트들을 대부분 기한을 맞춰야하는 시간 기반의 이벤트들이다. 예를 들어 게임 플레이어가 A 지점에서 B 지점으로 이동하는 경우, 게임 플레이어가 B 지점에 도착하기 전에 B 지점과 연관된 데이터들을 위한 파일들을 게임 프로그램이 획득해야한다. 게임 구성요소들은 미디어에서 데이터를 추출하는 저수준(low level)의 I/O 프리미티브(primitive)를 사용할 수 있지만, 이러한 프리미티브들은 다수의 구성요소들이 동시에 같은 장치로부터 데이터를 요구할 때 장치의 경합(contention)을 소화하지 못한다. 재밍된(jammed) I/O 요청들은 데이터 스트리밍의 흐름을 방해하거나 필요할 때 중요한 데이터 청크들이 구성요소로 전송되지 못하게 할 수 있다. 989Sound's Streamsafe와 같은 더 높은 수준의 시스템들은 파일들에 대한 적어도 신뢰가능한 스트림 접근을 제공하여서 스트리밍 되는 데이터가 방해되지(interrupted) 않는다.
일반적으로 어플리케이션의 구성요소들이 서로의 I/O 활동들에 대하여 인식하고 있지 않기 때문에, 구성요소들의 I/O 요청들은 종종 상당량의 (데이터를 검색하기 위해 왔다갔다하는)과다 탐색으로 고도의 비효율적 I/O 패턴을 초래한다. 게임 용량이 커지면서 과다 탐색과 비효율적 데이터 추출 과정이 늘어나는 추세에 있다. 배포용 미디어(distribution media)의 디스크 마스터링(disc mastering)은 자주 접근되는 데이터 블록들을 복사하고, 그들을 디스크 전반에 배포시켜서, 저장부의 판독 헤드가 어디에 있든지 간에 복사본이 항상 그 근처에 있도록 하는 기술들을 통해 소정의 비효율성을 줄이도록 도울 수 있다. 파일 시스템들은 데이터가 디스크 상 어느 물리적 위치에 있는지 항상 드러내 보이지 않기 때문에 I/O 시스템들이 데이터를 잘 활용할 수 없다.
이와 같은 배경으로부터 본 발명의 실시예들이 안출되었다.
본 발명의 한 실시예에 따르면 미디어 장치와 왕복적으로 입출력(input or output; I/O)하는 과정을 처리하기 위한 방법은 프로세서부, 메모리 및 미디어 장치를 구비한 시스템에서 구현될 수 있다. 미디어 장치와 왕복적으로 데이터를 전달하기 위한 인커밍 I/O 요청은 프로세서에서 실행되는 어플리케이션(application)으로부터 수신될 수 있다. 인커밍 I/O 요청을 완료하기 위한 예상 시간(TP)을 연산될 수 있다. 스케줄 내 인커밍 I/O 요청의 위치는 적어도 부분적으로 예상 시간(TP)에 의존할 수 있다. 인커밍 I/O 요청은 스케줄에 따라 수행(service)될 수 있다.
소정의 실시예들에 있어서, 프로세서 실행 가능한 인스트럭션들의 일군은 메모리에 내장될 수 있다. 인스트럭션들은 실행 시 상술된 방법들을 구현하도록 설정될 수 있다. 프로세서 실행 가능한 인스트럭션들의 일군은 하나 이상의 미디어 필터 계층들을 포함할 수 있다. 미디어 필터 계층들은 디아카이버(de-archiver) 계층, RAM 캐시 계층, 스케줄러 캐시(예. 하드 디스크 드라이브(HD) 캐시)) 계층, 오버레이(overlay) 계층, 카탈로그(catalog) 캐시 계층, 데이터 변환 계층, 또는 시뮬레이션 된 데이터 계층을 포함할 수 있다.
소정의 실시예들에 있어서 예상 시간(TP)은 미디어 장치의 하나 이상의 파라미터와 인커밍 I/O 요청으로부터 판단되는 하나 이상의 계수(coefficient)를 포함하는 성능 특징 수학식(performance characteristic equation; PCE)을 산출될 수 있다. 이로 한정되지 않지만 예를 들면, 파라미터들은 요청 오버헤드 x(request overhead x), 헤드 움직임 속도 y(head movement rate y) 및 처리량 z (throughput z)을 포함할 수 있다. 이러한 예에서, 계수들로는 오버헤드 계수 A(overhead coefficient A), 헤드 이동 거리 B(head travel distance B) 및 전송할 데이터 용량 C(amount of data to transfer C)가 될 수 있다. 성능 특징 수학식은 TP = Ax + By + Cz가 될 수 있다.
소정의 실시예들에 있어서, I/O 요청에 대한 PCE 계수들은 I/O 요청과 초기 미디어 상태에 기초하여 결정될 수 있다. 초기 미디어 상태는 성능에 영향을 주는 장치의 상태에 관한 하나 이상의 정보들을 포함할 수 있다. 예를 들면, 하나 이상의 정보는 장치의 준비 상태 그리고 최근에 접속된 논리 블록 주소(logical block address; LBA)가 될 수 있다. 어떠한 실시예들에 있어서, I/O 요청과 초기 미디어 상태로부터의 PCE 계수들을 산출하는 과정은 다른 PCE 산출 과정에서 초기 미디어 상태로 사용될 수 있는, 갱신된 미디어 상태를 리턴할 수 있다.
소정의 실시예들에 있어서, PCE 계수들은 PCE 내 미지 값들(unknown values)과 조합되어 주어진 어떠한 I/O 요청에 대한 예상 시간(TP)를 산출할 수 있다. I/O 요청들의 순서 리스트에 대한 총 시간(T)은 리스트에 있는 I/O 요청 각각에 대한 PCE와 미디어 상태를 반복 수행하고, 그 결과물인 TP 시간들을 더함으로써, 잇따라 산출될 수 있다. 이러한 공정은 I/O 요청 순서 리스트의 일부 또는 모든 순열(permutation)에 대하여 반복될 수 있다. 바람직한 순서 리스트는 각 순서의 연산된 총 시간(T) 그리고 다른 조건 등에 기초하여 복수의 순열들 중에 선택될 수 있다. 소정의 실시예들에 있어서, 바람직한 순서는 최소 시간(T)을 초래하는 순열이 될 수 있다. 순서에 영향을 주는 추가적인 조건으로는 (이로 한정되지 않지만) I/O 요청 우선순위, 스트림 버퍼 상태 및 대기 시간 조건을 포함할 수 있다.
소정의 실시예들에 있어서, I/O 요청을 수행하는 실제 시간(Ta)은 측정되고 상기 하나 이상의 계수와 함께 하나 이상의 미지의 파라미터(unknown parameter) 값을 위하여 상기 PCE를 반복적으로 푸는(solve)데 사용될 수 있다. 이는 모델에서 실제 드라이브 성능이 지속적으로 갱신되도록 한다.
어떠한 실시예들에 있어서, I/O 요청을 구현하는 과정은 압축되고 네스팅 된 아카이브로부터 특정 데이터를 추출하는 과정을 더 포함한다.
소정의 실시예들에있어서, 프로세서부는 메인 프로세서와, 연계된 로컬 메모리를 구비한 보조 프로세서를 포함할 수 있다. 이러한 실시예들에서 I/O 요청을 구현하는 과정은 데이터를 미디어 장치에서 로컬 메모리로 전송하고, 보조 프로세서를 사용하여 로컬 메모리에 있는 데이터를 변환하는 과정을 포함할 수 있다.
어떠한 실시예들에 있어서, 시스템은 그래픽 프로세서와 그와 연계된 그래픽 메모리를 더 포함할 수 있다. 이러한 실시예들에서 I/O 요청을 구현하는 과정은 데이터를 미디어 장치에서 그래픽 메모리로 전송하고, 그 데이터를 그래픽 메모리에서 로컬 메모리로 전송하고, 변환된 데이터를 생성하기 위해 보조 프로세서를 사용하여 데이터를 변환하는 과정을 수행하고, 변환된 데이터를 다시 그래픽 메모리로 전송하는 과정을 포함할 수 있다.
소정의 실시예들에 있어서, I/O 요청을 구현하는 과정은 데이터 오버레이를 구현하는 과정을 포함할 수 있다. 이때 미디어 장치외 메모리 사이에서 전송되는 하나 이상의 주 데이터 유닛들이 하나 이상의 제 2 데이터 소스로부터의 제 2 데이터 유닛들로 대체된다. 주 데이터 유닛들의 소스와 제 2 데이터 소스는 동일 미디어나 서로 다른 미디어에 위치할 수 있다. 제 2 데이터 소스는 가상 데이터 소스일 수 있다. 제 2 데이터 유닛들은 콜백에 의해 특정될 수 있다.
어떠한 실시예들에 있어서, 시스템은 고속 기억장치를 더 포함할 수 있다. 이러한 경우, I/O 요청을 구현하는 과정은 하나 이상의 데이터 유닛들을 미디어 장치에서 고속 기억장치로 프리 페치하고, 고속 기억장치로부터의 데이터 유닛들을 잇따라 전송하는 과정을 포함할 수 있다. 예를 들면, 고속 기억장치는 하드 디스크 드라이브이고, 미디어 장치는 블루 레이 디스크 드라이브와 같은 고용량 광디스크 드라이브가 될 수 있다. 데이터 유닛들은 I/O가 대기 상태 인 시간동안에 프리 페치될 수 있다. 소정의 실시예들에 있어서 프리 페치하는 과정은 미디어 장치로부터의 하나 이상의 데이터 유닛들의 제 1 그룹을 프리 페치하는 과정과, 미디어 장치의 대기 상태 여부를 확인하는 과정과, I/O 가 대기 상태에 있으면, 미디어 장치로부터의 하나 이상의 데이터 유닛들의 제 2 그룹을 프리 페치하고, I/O가 대기 상태에 있지 않으면, 제 2 그룹의 프리 페치 과정을 지연하는 과정을 포함할 수 있다.
소정의 실시예들에 있어서, 예상 시간(TP)을 연산하는 과정은 시스템과 연관된, 미디어 장치 보다 더 느린 미디어 장치의 작업을 에뮬레이션 하기 위해 하나 이상의 파라미터들을 조정하는 과정을 포함할 수 있다.
본 발명의 한 실시예에 따르면, 미디어 장치와 왕복적으로 입출력(input or output; I/O)하는 과정을 처리하기 위한 방법은 메인 프로세서, 연계된 로컬 메모리를 구비한 보조 프로세서, 메인 메모리 및 미디어 장치를 구비한 시스템에서 구현될 수 있다. 이러한 방법은: a) 미디어 장치와 왕복적으로 데이터를 전달하기 위해 메인 프로세서에서 실행되는 어플리케이션(application)으로부터의 인커밍(incoming) I/O 요청을 수신하는 과정과, b) 메인 메모리에 내장된 스케줄에 인커밍 I/O 요청을 삽입하는 과정과, c) 스케줄 및 하나 이상의 필터에 따라 인커밍 I/O 요청을 수행(service)하는 과정을 포함하고, 하나 이상의 필터 중 적어도 하나는 보조 프로세서에 의해 구현되는 것을 특징으로 한다.
본 발명의 설명은 하기 상세한 설명과 첨부된 도면들을 참조해서 고려함으로 빠르게 이해될 수 있다. 첨부된 도면들 중:
도 1은 본 발명의 실시예에 따른 파일 I/O 시스템(FIOS)을 구현하는 시스템의 블록도이고,
도 2는 본 발명의 다른 실시예에 따른 FIOS를 구현하는 다른 시스템의 블록도이고,
도 3은 본 발명의 실시예에 따른 FIOS 소프트웨어의 블록도이고,
도 4는 본 발명의 실시예에 따른 FIOS에서의 과정들을 도시하는 흐름도이고,
도 5는 본 발명의 실시예에 따른 FIOS에서 사용되는 소프트웨어 스케줄러의 일례를 도시하는 흐름도이고,
도 6은 본 발명의 실시예에 따른 FIOS에서 프리 페치하는 과정의 일례를 도시하는 개략도이고,
도 7a는 본 발명의 실시예에 따른 연계된 로컬 메모리를 가진 보조 프로세서를 사용하여 I/O 버퍼링을 하는 일례를 도시하는 흐름도이고,
도 7b는 본 발명의 실시예에 따른 연계된 로컬 메모리를 가진 보조 프로세서를 사용하여 I/O 버퍼링과 데이터 변환 과정의 일례를 도시하는 흐름도이고,
도 8은 본 발명의 실시예들과 함께 사용될 수 있는 네스팅 된 아카이브의 데이터 구조를 도시하는 블록도이며,
도 9는 본 발명의 실시예에 따른 디아카이버를 도시하는 흐름도이다.
하기 상세한 설명은 도시적 목적으로 특정 요소들을 포함하고 있지만 당업자라면 하기 설명의 많은 변경물과 변형물들이 본 발명의 범위 내에서 존재할 수 있음을 인지할 것이다. 이에 따라 하술된 본 발명의 실시예들은 어떠한 일반성을 잃지 않고, 청구된 발명을 한정시키지 않으며 개진된다.
본 발명의 실시예들은 파일 입출력 시스템(file I/O system; FIOS) 주변에서 구현될 수 있다. 이러한 FIOS는 시스템의 모든 I/O가 통과하는 중앙집중된 계층을 제공한다. 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)는 예를 들어 FIOS 프로그램(101)에 의해 사용되는 인커밍 I/O 요청, 스케줄된 I/O 요청, 발행된 I/O 요청, 완료된 I/O 요청 및 프리 I/O 요청을 위한 스택(stack)이나 큐(queue)의 형태의 I/O 큐들(101Q)을 포함할 수 있다. 이러한 큐들의 예는 하기에서 설명된다.
예를 들어 FIOS 프로그램(101)은 하기와 같은 인스트럭션들을 포함할 수 있다.
a) 미디어 장치(118)와 관련된 인커밍 I/O 요청을 어플리케이션(103)으로부터 수신하는 인스트럭션.
b) I/O 요청을 안료하는 예상 시간(TP)을 산출하는 인스트럭션.
c) 메모리(106)에 내장된 스케줄의 한 장소에 인커밍 I/O 요청을 적어도 부분적으로 예측된 시간(TP)에 기초하여 삽입하는 인스트럭션.
d) 스케줄에 따라 I/O 요청을 구현하는 인스트럭션.
FIOS 프로그램(101)은 인터렉티브한 환경을 구현하도록 설정된 하나 이상의 인스트록션들과 함께 동작할 수 있다. 예를 들어 이러한 인스트럭션들은 비디오 게임 프로그램과 같은 메인 프로그램(103)의 서브루틴(subroutine) 이나 호출가능한 기능(callable function)이 될 수 있다. 선택적으로 메인 프로그램(103)은 가상 세계와 인터페이스하기 위한 프로그램이 될 수 있다. 메인 프로그램(103)은 비디오 표시부에 있는 카메라 관점에서 시뮬레이션 되는 환경의 일부 장면을 표시하고, 시뮬레이션 되는 환경과 사용자가 상호작용하는 동안 카메라 경로에 따른 카메라 관점의 움직임에 반응하여 카메라의 관점이 변경됨에 따라 장면을 변경하도록 설정될 수 있다. 메인 프로그램은 물리 시뮬레이션(104) 및 카메라 관리(107)를 위한 인스트럭션들을 포함할 수 있다. 메인 프로그램(103)은 기능이나 서브루틴과 같은 FIOS 프로그램(101), 물리 시뮬레이션 인스트럭션들(104), 카메라 관리 인스트럭션들(107) 및 광고 효과 리포트 인스트럭션들(109)을 호출할 수 있다.
또한 클라이언트 시스템(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 장치들(111)을 통해 클라이언트 장치(100)에 연결될 수 있다. 적합한 입력 장치들(120)의 예로는 키보드, 마우스, 조이스틱, 터치 패드, 터치 스크린, 광 펜, 스틸(still) 또는 비디오 카메라 그리고/또는 마이크가 될 수 있다. 클라이언트 장치(100)는 전자 통신 네트워크(127)를 통한 통신을 용이하게 하는 네트워크 인터페이스(125)를 포함할 수 있다. 네트워크 인터페이스(125)는 근거리 통신망과 인터넷과 같은 광역통신망을 통한 무선 또는 유선 통신을 구현하도록 설정될 수 있다. 시스템(100)은 네트워크(127)를 사용하여 하나 이상의 메시지 패킷들(126)을 통해 데이터 그리고/또는 네트워크(127)를 사용하여 하나 이상의 메시지 패킷들(126)을 송수신할 수 있다.
시스템(100)은 그래픽 처리부(GPU)(135)와 그래픽 메모리(140)를 구비할 수 있는 그래픽 서브시스템(130)을 더 포함할 수 있다. 그래픽 메모리(140)는 출력 이미지의 픽셀 각각을 위한 픽셀 데이터를 저장하는데 사용되는 표시부 메모리(예. 프레임 버퍼(frame buffer))를 포함할 수 있다. 그래픽 메모리(140)는 GPU(135)와 같은 장치에 통합되거나, GPU(135)와 분리된 장치로 연결되거나, 그리고/또는 메모리(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 프로그램(205)의 코딩된 인스트럭션들을 실행할 수 있다.
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 프로그램(205)의 일부를 구현하는 인스트럭션들(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 프로그램(209)과 동일한 특징들을 가진 FIOS 프로그램(101)의 일부를 내포할 수 있다. 적어도 하나의 SPE(206)는 그의 로컬 저장부에 사훌되는 데이터 복원 과정(decompression)을 구현하도록 설정된 코드(207)를 구비한다. PPE(204)는 내부 캐시(L1)과 외부 캐시(L2)를 포함할 수 있다. PPE는 내부 캐시(L1)에 FIOS 프로그램(205)의 일부를 저장할 수 있다. FIOS 프로그램(205)과 SPE 구현 가능한 파일 전송 인스트럭션들(207)이나 이들의 일부 또한 메모리(202)에 저장될 수 있어서, SPE(206)와 PPE(204)가 필요로 할 때 접속될 수 있다.
예를 들면 도 3에 도시된 바와 같이 FIOS 프로그램(101/205)은 저장부(115)와 같은 하드웨어와 인터페이스 하는 과정을 용이하게 하는 미디어 스택(media stack)을 포함할 수 있다. 미디어 스택은 도 3에 도시된 바와 같이 구현될 수 있다. 특히, 미디어 스택은 스케줄러(302), 하나 이상의 미디어 필터 계층(304), 장치 미디어 계층 (306), 프로세서 파일 시스템(file system; FS) 판독 계층(308) 및 하드웨어 계층(310)을 포함할 수 있다. (종종 미디어 접속 계층으로 불리는) 장치 미디어 계층(306)은 상기의 미디어 필터 계층들(304)로부터 수신된 미디어 요청들에 반응하도록 설정될 수 있다. 따라서 장치 미디어 계층(306)은 요청된 데이터를 추출하고, 그런 다음 응답을 스택으로 송신한다.
미디어 필터 계층들(304)은 디아카이버 계층(301), RAM 캐시 계층(303), 스케줄러 캐시 계층(305), 오버레이(overlay) 계층(307), 카탈로그(catalog) 캐시 계층(309), 하나 이상의 데이터 변환 계층(311), 시뮬레이션 된 데이터 계층(313) 및 스피드 에뮬레이션 계층(315)을 포함할 수 있다.
디아카이버(301)는 압축된 아카이브들(archives)로부터 특정 자산 파일들(asset files)을 추출하는 과정을 용이하게 하는데 사용될 수 있다. RAM 캐시 계층(303)은 일례로, 메인 메모리(106, 202)에 데이터를 캐시하는 과정을 구현하는 데 사용될 수 있다. 스케줄러 캐시(305)는 광 디스크와 같이 비교적 느린 소스로부터의 데이터를 임시 저장하기 위해 간단한 디스크 대 디스크(disc-to-disc) 캐시가 될 수 있다. 본 명세서에서 사용된 '스케줄러 캐시'라는 용어는 미디어 장치(118) 보다는 빠르게 접속할 수 있는 저장 매체 내의 임시 데이터 저장소를 가리킨다. 스케줄러 캐시(305) 내에 있는 모든 데이터가 프리페치(pre-fetch) 될 필요는 없다. 일부 데이터는 요구가 있는 즉시 패치(patched)되고 캐시로 카피될 수 있다.
일례로 이로 한정되지는 않지만, 스케줄러 캐시 계층(305)은 고속 저장 매체(115)를 이용하여 이러한 임시 저장소를 제공한다. 고속 저장 매체가 하드 디스크 드라이브(HDD)인 특정 경우에 있어서, 스케줄러 캐시(305)는 때때로 HDD 캐시로 불린다.
스케줄러 캐시(305)는 단일 또는 다수의 파일로 보유될 수 있다. 또한 스케줄러 캐시(305)의 콘텐츠가 파일들 전체가 될 필요는 없다. 다수의 파일로 된 캐시는 지나친 데이터를 희생하지 않고도, 필요 시 디스크 공간을 지능적으로 비우기 위해 약간의 파일들 각각을 삭제함으로써, 부분적으로 플러쉬(flush)될 수 있다. 이에 대비하여, 단일의 파일로 된 캐시는 일반적으로 절단되거나(truncated), 전체적으로 삭제될 뿐이다. 단일의 파일로 된 캐시는 다수의 파일로된 캐시들보다 더 높은 성능을 제공할 수 있다. 이는 다수의 파일로 된 캐시는 주로 별도의 I/O를 필요로하는 추가적인 (호스트 파일 시스템 자체 내에서)부기(bookkeeping) 작업을 요구하기 때문이다.
오버레이 계층(307)은 하술된 바와 같이 파일 시스템 레벨에서 파일 및 디렉토리들이 임의로 오버레이 되도록 하는데 사용될 수 있다. 카탈로그 캐시 계층(309)은 처리부(105)나 셀 프로세서(200)의 O/S가 올바르게(properly) (예. 파일 존재, 크기 및 위치)캐시하지 않은 데이터를 캐시하는데 사용될 수 있다. 데이터 변환 계층(311)은 미디어 장치(118)로부터 판독되거나 기록되는 데이터의 복호화, 부호화, 압축 또는 복원과 같은 데이터 변환 과정을 구현할 수 있다. 시뮬레이션 된 데이터 계층(313)은 일례로 이와 같이 시뮬레이션 된 데이터를 요구하는 I/O 요청들을 위해 제로들이나 임의의 수를 생성하는데 사용될 수 있다. 스피드 에뮬레이션 계층(315)은 일례로 소프트웨어 개발 중에, 하기와 같이 다른 속도를 가진 미디어 장치들을 시뮬레이션 하는데 사용될 수 있다.
스케줄러(302)의 운용 과정은 하술된 도 4를 참조하여 설명한다. 클라이언트의 관점에서 볼 때, I/O 요청(403)은 비교적 단순한 방식으로 수행될 수 있다. 예를 들어 비디오 게임과 같은 어플리케이션(401) 내의 스레드(402)는 기능(예. readFile())을 불러서 FIOS 프로그램(101/205)을 통하여 I/O를 요청할 수 있다. 이러한 기능은 FIOS 요청(403)의 우선순위와 요청(403)이 완료되어야할 기한을 명시할 수 있다. 또한 이러한 기능은 버퍼(405)로의 포인터를 제공할 수 있다. 이러한 구현 방법은 I/O 요청(403)에 대한 I/O 작업 구조를 원자적으로 할당하고 새로 할당된 작업을 인커밍 큐(404)로 옮긴다. 예를 들면, 인커밍 큐(404)는 큐(404)에 첫 번째로 넣어진 작업이 스케줄러(302)에 의해 스케줄되는 첫 번째 작업이 되는, 선입선출법(first-in-first-out; FIFO)을 사용하는 큐가 될 수 있다. 요청(403)을 인커밍 큐(404)에 삽입하는 과정은 비동기식(asynchronous) I/O를 요청할 때 스레드들이 차단되는 것을 방지하는, 원자적 연산(atomic operation)에 의해 구현될 수 있다. 수정의 실시예들에 있어서, 인커밍 큐(404)는 보조 프로세서(105B)에 의해 원자적 교환으로 채워질 수 있는 원자적 스택의 형태를 가질 수 있다.
예컨대 이로 한정되는 것은 아니지만, I/O 요청(403)이 판독 작업을 요청하면, 클라이언트 어플리케이션(401)은 미디어 장치로부터 추출한 데이터를 수신하는 버퍼를 공급할 수 있다. I/O 요청이 완료될 때, 클라이언트 어플리케이션은 공급한 버퍼에서 추출된 데이터를 판독할 수 있다. 클라이언트가 I/O 요청을 처리하는 과정을 마칠 때, 클라이언트는 버퍼를 할당해제(de-allocate)해서 그의 리소스들이 미래에, I/O 용도로 사용될 수 있도록 한다.
I/O 요청(403)은 스케줄러(302)가 이미 활성화되지 않은 경우, 스케줄러(302)를 활성화한다. 그리고 I/O 요청(403)은 상기 구조로 사용자에게 보이는 핸들(handle)을 리턴해서, 어플리케이션(401)이 작업에 접속할 수 있도록 한다. 그런 다음 어플리케이션(401)은 완료될 I/O 요청(403)을 기다릴 수 있다. 예를 들면, 클라이언트 어플리케이션(401)은 원자적 방법(예. isDone())을 사용하여 주기적으로 폴링(polling)한다. 선택적으로, 클라이언트는 I/O 요청 완료 시, 스케줄러(302)가 부르는 콜백 기능을 기다릴 수 있다.
I/O 요청이 인커밍 큐(404)에 삽입된 후, FIOS 프로그램(101/205)은 스케줄러(302)가 스케줄 삽입 과정(407)을 수행하도록 유발할 수 있다. 스케줄러에 의해 구현되는 일련의 과정들은 도 5를 참조해서 이해될 수 있다. 스케줄러(302)는 502 과정에 표시된 바와 같이 처리할 I/O가 없으면 슬립 상태(sleep)(즉, 비활성화 상태 유지)에 있을 수 있다. 새로운 I/O 작업이 인커밍 큐로 진입할 때 스케줄러는 이를 처리하기 위해 어웨이크(awake) 한다. 스케줄러가 어웨이크 한 후( 또는 이미 어웨이크한 경우), 스케줄러는 인커밍 큐에 있는 새로운 작업을 인지하고, 스케줄 큐(406)의 적합한 위치로 작업을 이동시킨다.
I/O 요청(403)의 큐 위치를 결정하기 위해 스케줄러(302)는 선택적으로 503 과정에 표시된 바와 같이 예를 들어 장치 미디어 계층(306)이나 FIOS 미디어 스택(300)에 있는 다른 계층을 조회(query)함으로써, 미디어 장치의 현재 상태를 파악할 수 있다. 상태를 나타내는 데이터는 FIOS 미디어 스택(300)에 의해 취급되는 미디어 장치의 종류와 스택에 존재하는 다양한 계층들에 따라서 달라질 수 있다. 예로 포함되는 것으로는, 최근에 접속된 논리 블록 주소(logical block address; LBA), RAM 캐시의 마지막으로 접속된 경로 및 오프셋, 현재 디스크 계층, 헤드(head) 위치, 스트리밍(streaming) 모드 및 비스트리밍(non-streaming) 모드 등이 있다.
본 발명의 실시예들에 따르면 스케줄러(302)는 미디어 장치 성능 모델(302A)에 기초할 수 있다. 현재의 I/O 스케줄러들과는 다르게, 드라이브 모델(302A)은 요청(403)을 처리하기 위한 최적의 스케줄을 결정하는데 있어서 미디어 장치(118)의 성능에 관한 데이터를 참조할 수 있다. 드라이브 모델을 사용하여 I/O 요청들을 스케줄하는 과정은 CD를 생성하는 데에 있어서 마스터링 처리 과정이 도치(倒置)(inverse)된 과정에 비교될 수 있다. 성능 모델(302A)은 오버헤드(overhead), 디스크 이동 시간, 판독 시간 등과 같은 요소들을 고려하도록 설정될 수 있다. 성능 모델(302A)은 처리량(throughput), 레이저의 흔들림(wiggles), 판독 헤드의 움직임, 레이어 변경 및 요청 오버헤드와 같은 미디어 장치(118)의 임의로 복잡한 특성들을 모델링할 수 있다. 또한 성능 모델(302A)은 I/O 요청에 연관된 미디어 장치(118)에 의해 판독되거나 기록되는 특정 매체의 다른 파라미터들을 참조할 수 있다. 예를 들어, 성능 모델(302A)은 장치가 단일 레이어 디스크나 다수 레이어 디스크(예. 블루 레이 DMD와 같은 듀얼 레이어 디스크)를 판독하는 지 고려할 수 있다.
또한 스케줄러(302)는 504 과정에 표시된 바와 같이 새로운 I/O 작업의 시간 요구 사항들(예. 기한)과 우선순위를 선택적으로 참조할 수 있다. 이에 더하여 스케줄러는 506 과정에 표시된 바와 같이, 인커밍 I/O 요청을 완수하기 위한 예상 시간(TP)을 연산하도록 설정될 수 있다. 바람직한 실시예에 따르면, 스케줄러(302)는 미디어 장치(118)와 연관된 여러 파라미터들과 인커밍 I/O 요청(403)과 연관된 하나 이상의 계수(coefficient)들을 포함하는 성능 특징 수학식(performance characteristic equation; PCE)에 따라 I/O 요청(403)을 실행하기 위한 예상 시간(TP)을 판단할 수 있다.
PCE는 하기와 같은 일반식이 될 수 있다.
TP=Af1(x)+Bf2(y)+Cf3(z)+Df4(w)+Ef5(v)+...,
이때 A, B, C, D 및 E는 계수들이고, x, y, z, w 및 v는 미디어 장치의 성능 특징들과 연관된 파라미터들을 나타내고, f1(x), f2(y), f3(z), f4(w) 및 f5(v) 등은 x, y, z, w 및 v의 함수이다. 예를 들면, PCE는 하나 이상의 항들(terms)을 더하는 1차 방정식이 될 수 있다. 이때 각각의 항들은 계수(A, B, C 등)와 파라미터 항(x, y, z 등)을 곱한 항들이다. 이러한 수학식은 하기와 같다.
TP=Ax+By+Cz+Dw+Ev+...
이러한 수학식은 임의의 수만큼의 항들을 가질 수 있다. 변수들은 요구되는 작업을 수행하는데 드는 시간에 영향을 미치는, 미디어 장치의 소정의 파라미터에 대응한다. 이러한 파라미터들의 예로는 오퍼헤드, 탐색 시간(seek time) 및 데이터 전송 속도가 있다. 실제로 PCE는 일례로 10 개 이상의, 3 개의 항들 보다 많은 수의 항들을 사용할 수 있다. 예를 들면 단일의 판독 작업은 주로 이를 나타내기 위해 여섯 개의 주요 항들이 사용된다: 파일 열림, 오버헤드, 탐색, 전송, 복원 및 파일 닫힘. 다른 작업들(열림, 닫힘, 링크 해제(unlink, 디렉터리 판독)은 주로 다른 항들의 일군을 필요로 한다.
1차 방정식의 대체예로, PCE는 다항 방정식으로 확장될 수 있다. 즉, 계수와 변수의 몇 제곱의 곱셈인, 하나 이상의 항들의 합이 될 수 있다. 예를 들면 하기와 같은 수학식이 될 수 있다.
Tp=Ax+By+Cz2+Dw10+Ev-2...
다른 대체예로는, PCE가 하나 이상의 항들의 합으로 표현되는 일반식으로 확장될 수 있다. 이때 각 항들은 계수가 그와 대응하는 변수의 임의의 방정식과 곱해진 항이다. 일례로 PCE는 아래와 같을 수 있다.
Tp=Ax+Blogy+Cez+D(w2+2w+1)+...
간단한 예로, PCE는 1차 방정식인 TP = Ax + By + Cz가 될 수 있다. 이때 x 는 요청(403)에 대한 오버헤드와 연관되고, y 는 움직임의 섹터 당 헤드의 움직임 시간이고, z는 데이터 처리 속도(data throughput rate)(예. 주어진 데이터량을 판독하거나 기록하는 시간)와 관련될 수 있다. 계수들 A, B 및 C의 값은 스케줄 큐(404) 내에 있는 요청(403)의 위치에 의존할 수 있다.
예를 들면, 계수들 A, B, 및 C는 상태나 요청(403) 내 정보로부터 결정될 수 있다. 일례로, 하나 이상의 정보는 장치의 준비 상태와 최근에 접근된 논리 블록 주소가 될 수 있다. 최근 논리 블록 주소는 드라이브의 판독 헤드의 현 위치를 표시하여 탐색 거리(헤드의 이동 거리)를 연산하도록 할 수 있다.
본 예에서, 계수 A는 본 명세서에서 오버헤드 계수로 지칭된다. 이러한 계수는 오버헤드가 부분적으로 I/O 요청(403)의 본질과 미디어 장치(118)의 특성들에 의지한다는 점을 감안한다. 계수 B는 데이터가 판독되어야 할 미디어 내 위치로 가기기 위해 미디어 장치(118) 내 판독 헤드가 움직이어야 하는 헤드 움직임 량에 연관될 수 있다. 예를 들면 요청(403)은 미디어 장치(118)가 섹터 1000에서부터 열 개의 섹터들을 판독하도록 호출할 수 있다. 이와 같은 경우, 데이터 계수 C는 판독되어야 할 섹터들의 수가 될 수 있다. 움직임 계수 B는 장치 미디어 계층(306)에서 획득되는 상태 정보로부터 결정될 수 있다. 상태 정보는 I/O 요청 시작 시 판독 헤드의 초기 위치를 포함할 수 있다. 예를 들어 판독 헤드가 처음에 섹터 500에 있었으면, 움직임 계수 B는 판독 과정이 시작한 섹터(섹터 1000)와 현재 섹터(섹터 500) 사이의 차이로부터 판단될 수 있다. (즉, B = 1000 - 500 = 500.) 스케줄러(302)는 I/O 요청(403)이 완료된 후 마지막 상태를 판단할 수 있다. 예를 들어 열 개의 섹터들이 섹터 1000에서 시작되어서 판독되었다면, 마지막 상태는 섹터 1010에 머무르는 판독 헤드를 표시할 것이다.
또하 PCE는 I/O 요청을 채우기 위한 다른 다양한 시나리오들을 고려할 수 있다. 예를 들어 미디어 장치(118)가 다중 계층 매체를 사용하면, PCE는 하나의 계층에서 다른 계층으로 판독 헤드를 움직이는 과정이 예상 시간(TP)에 영향을 준다는 점을 고려할 수 있다.
소정의 실시예들에 있어서, 어떠한 I/O 요청에 대한 실제 시간(Ta)은 측정되고 PCE 계수들과 함께 사용되어서, 미지의 변수 값들을 위하여 PCE를 반복적으로 풀(solve) 수 있다. 이는 모델이 실제 드라이브 성능으로 지속적으로 갱신되도록 한다.
예상 시간(TP)가 산출되고 나면, 스케줄러(302)는 비슷한 방식으로 스케줄 큐(406)에 있는 다른 요청들의 예상 시간들을 판단할 수 있다. 이러한 과정은 507 과정에 표시된 바와 같이 요청(403)의 실제 시간과 최고의 스케줄 큐 순서를 판단할 때 까지 다른 큐 순서들을 가지고 반복적으로 재수행 될 수 있다. 요청(403)의 초기 상태는 스케줄 순서에 있는 이전 요청을 위한 마무리 상태로부터 판단될 수 있고, 스케줄 순서에 있는 다음 요청을 위한 초기 상태는 요청(403)의 마지막 상태에서 판단될 수 있다.
스케줄러(302)는 스케줄 큐에 있는 요청들을 하나씩 처리해 나갈 수 있다. 이 때 스케줄러(302)는 요청(403)의 특징들을 이미 큐에 있는 요청들과 비교할 수 있다. 스케줄러(302)는 큐에서 가능한 위치들 각각에 요청(403)을 배치해볼 수 있다. 이 때 스케줄러(302)는 우선순위를 무효화하는 과정(overrides), 놓친 기한들 및 시간 참작(time consideration)을 찾아볼 수 있다. 스케줄러(302)는 어떠한 요청된 I/O 과정도 기한을 놓치지 않는 순서를 검색함으로써 최고의 새로운 큐 순서를 판단할 수 있다. 만약 하나 이상의 요청들이 기한을 놓치면, 스케줄러는 다른 기준을 사용하여 큐 순서를 결정 할 수 있다. 스케줄 큐(406)에 있는 요청들의 순서에 영향을 줄 수 있는 추가적인 기준으로는 이에 제한되지는 않지만, I/O 요청 우선순위들, 스트림 버퍼 상태들 및 대기(latency) 요건들이 될 수 있다. 소정의 실시예들에 있어서, 하나의 TP 선출을 위한 PCE 계수들은 갱신된 미디어 상태를 리턴하는데 사용될 수 있다. 갱신된 미디어 상태는 다른 PCE 산출 과정을 위한 초기 미디어 상태로 사용될 수 있다.
한 실시예에 따르면, 스케줄러(302)는 다양한 삽입 순열들을 확인할 수 있다. 일례로, 작업 1, 작업 2 및 작업 3을 포함하는 스케줄 내에 작업 4를 삽입할 수 있다. 각각의 순열은 다른 총 시간(T)을 배출한다. 가능한 순열 및 시간들은 아래와 같다.
4, 1, 2, 3 → T1
1, 4, 2, 3 → T2
1, 2, 4, 3 → T3
1, 2, 3, 4 → T 4
스케줄러(302)는 어떤 순열이 최소의 총 시간(T)을 추측하는지 판단하고, 그 순열을 바람직한 순열로 사용할 수 있다.
또한 스케줄러(302)는 추측되는, 놓친 기한을 확인할 수 있다. 즉, 스케줄 된 아이템들 각각의 시간을 합해서, 기한을 놓치는 스케줄 된 아이템이 있는 지 판단할 수 있다. 이는 스케줄 된 작업 각각에 대한 완료 시간을 판단하고, 그 작업의 기한과 완료 시간을 비교하는 과정을 포함할 수 있다. 만약 기한을 놓치면, 그 작업은 큐에서 더 빠른 위치로 재스케줄 될 수 있다.
어떠한 실시예들에 있어서, 예를 들어 기한들 모두가 해결될 수 없는 경우, 우선순위가 사용될 수 있다. 예를 들면, 만약 어떠한 기한들이 불가피하게 맞춰질 수 없을 경우, 최고의 큐 순서는 최하위 우선순위를 가진 요청들의 기한을 충족시키지 않는 순서가 될 수 있다. 만약 이러한 고려 사항을 충족시키는 다수의 큐 순서들이 있을 경우에는 동일한 운선순위를 가진, 마감일이 충족되지 않는 최소수의 요청들을 가진 큐 순서가 최고의 순서가 될 수 있다. 나아가, 만약 상술된 제약들을 만족시키는 다수의 큐 순서들이 있는 경우에는, 큐 전체를 실행하는데 추정된 최단 시간이 소요되는 큐 순서가 최고의 순서가 될 수 있다. 어떤 경우들에 있어서, 높은 우선순위의 요청이 기한을 맞출 수만 있다면, 낮은 우선순위의 요청이 높은 우선순위의 요청 전에 스케줄링 될 수 있다.
상술된 모든 고려사항들을 만족시키는 다수의 큐 순서들이 있는 경우에는, 스케줄 큐(406)에 있는 최근 요청이 큐의 마지막으로 가는 순서가 최고의 순서가 될 수 있다. 스케줄러(302)가 새로운 작업을 큐에 삽입하기 위해 큐가 실행되는 총 시간을 예측해야 된다면, 여러 요소들을 고려할 수 있다. 예를 들어 스케줄러는 스케줄러(302)가 큐 순서 평가 바로 전에 추출한 장치 드라이버의 현 상태를 고려할 수 있다. 또한 스케줄러(302)는 미디어 필터 계층들과 FIO 스택(300) 내에 있는 다른 계층들에 의해 보고되는 성능 계수들을 고려할 수 있다. 이러한 값들은 일례로 헤드 움직임, 헤드 정렬(head alignment), DMA 설정, 데이터 전송 속도, 저장 계층들을 위한 계층 변경 등을 포함할 수 있다. 이러한 값들은 I/O 성능에 대한 런타임 측정값들로 채워져서, 추정값들이 최대한 정확한 값에 가까워질 수 있다.
스케줄러(302)가 요청(403)을 수행하기 위한, 스케줄 큐(406)의 최고 위치를 파악한 후에는, 도 4의 407 과정 및 도 5의 508 과정에 표시된 바와 같이 그곳에 작업이 삽입될 수 있다. 도 4를 다시 참조하면, I/O 요청들을 실행하기 위한 리소스들이 가용하면, 스케줄러(302)는 409 과정에 표시된 바와 같이 스케줄 큐(406)에 있는 첫 번째 작업을 발행 큐(408)로 이동시킬 수 있다. 이에 작업과 연관된 미디어 요청은 발행 큐(408)에서 실행될 수 있다. 미디어 요청을 실행하기 위해, 스케줄러(302)는 그 요청을 FIOS 미디어 스택(300)에 있는 첫 번째 계층으로 보낼 수 있다.
스케줄러(302) 아래 계층들 각각은 상위 계층에서 보내진 미디어 요청(403)을 볼 수 있다. 적합한 경우, 계층은 데이터를 처리할 수 있다. 예를 들면, 요청이 판독 작업일 경우, 디아카이버 계층(301)이 보급된 경로 이름을 오픈 아카이브 콘텐츠들과 비교하고, 만약 파일을 찾으면, 압축된 데이터를 판독하는 것으로 요청을 다시 매핑할 수 있다. FIOS 미디어 스택(300)의 계층들 각각은 처리되거나 처리되지 않은 미디어 요청이 끝내 하드웨어 계층(310)에 다다를때 까지 그 다음으로 낮은 계층에 I/O 요청을 넘긴다. 하드웨어 계층(310)이 요청에 응할 때, 그 응답은 스택(300)에 있는 각각의 계층들을 상향식으로 통과하고, 적합하다면, 각각의 계층들은 추출된 데이터를 처리할 수 있다. 예를 들면, 디아카이버 계층(301)은 돌아온 데이터가 복원되어야만 하는 것을 인지할 수 있고, 이에 따라 스택으로 그 응답을 다시 보내기 전에 복원할 수 있다. 그 응답은 마지막으로 스케줄러(302)에게로 돌아간다.
추출된 데이터가 스택으로 다시 올 때, 스케줄러(302)는 그것을 수신하고, (어플리케이션에 콜백 기능이 설정된 경우) 어플리케이션(401)에 콜백 기능(411)을 유발할 수 있는, 완료된 큐로 I/O 작업을 옮길 수 있다. 선택적으로, 어플리케이션(401)은 I/O 작업이 완료되었는지 파악하기 위해 FIOS 스택(300)을 폴링 할 수 있다. I/O 작업이 완료되고나서는, 그것이 프리 I/O 풀(free I/O pool)(412)로 이동할 수 있다. 프리 I/O 풀(412)은 사용 중이지 않은 I/O 작업 구조 세트를 포함할 수 있다. 이러한 작업들은 클라이언트 어플리케이션에 할당된 적이 전혀 없거나, 클라이언트 어플리케이션에 의해 사용되었지만 재사용을 위하여 프리된(freed) 요청들일 수 있다. 클라이언트 어플리케이션이 I/O 요청을 작성할 때, 스케줄러(302)는 이러한 풀에 있는 클라이언트에게 I/O 작업을 할당할 수 있다. 프리 I/O 풀(412)은 스택으로 구현될 수 있다. 프리 I/O 요청들은 프리 I/O 풀(412)에서 나오거나(popped) 인커밍 큐(404)에 넣어질 수 있다. 이러한 방식으로, 프리 I/O 요청들은 재사용될 수 있다.
본 발명의 실시예들에 따라, 스케줄러(302) 하술된 바와 같이 스케줄 루프(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)가 공통적인 데이터 엘리먼트이면, 보조 프로세서는 메인 프로세서(105A)와의 표준 원자적 교환을 통해 I/O 요청을 큐에 추가하고, 메인 프로세서(105A)에 신호를 보낼 수 있다.
종래의 많은 구현 방법들에 있어서, 만약 보조 프로세서가 즉각적인 처리를 위해 데이터를 필요로 한다면, 데이터는 메인 메모리에 있어야만 했다. 본 발명의 실시예들에 따르면, 반대로 보조 프로세서(105B)가 FIOS 스택(300)이 하드 미디어 장치(118)로 부터나 네트워크(127)를 통해서 까지도 필요한 데이터를 가져올 수 있도록 유발할 수 있다.
예를 들면 이로 제한되지 않지만, 인커밍 큐(404), 완료된 큐(410) 및 프리 I/O 풀(412)은 원자적 스택들이 될 수 있다. 보조 프로세서(105B)는 프리 I/O 풀(412)로부터 하나의 작업을 꺼내고, 작업을 위한 경로를 기입하고, 작업을 인커밍 큐(404)로 다시 밀고(push), 그런 다음 동기화(synchronization) 과정을 수행하고 스케줄러(302)를 어웨이크 시킨다. 보조 프로세서는 I/O 작업이 완료를 위해 간간이 폴링하지 않는 동안에는 다른 작업을 수행할 수 있다.
예를 들어, 셀 프로세서 시스템(200)에 있어서, I/O 요청은 SPE(206)에 의해 하기 종류의 일련의 인스트럭션들을 사용하여 수행될 수 있다.
Op = pop(FREE)
Op path = …..
Offset = …..
Push (op, incoming).
SPE(206)에 의해 요청된 데이터는 PPE(204)에 의해 어드레스(address)로 불러낼 수 있는 어떤 곳으로도 전송될 수 있다. 만약 SPE(206)가 잠김 상태가 되면, FIOS(300)는 SPE(206)의 로컬 저장부(LS)에 직접적으로 데이터를 기록할 수 있다. 어떠한 실시예들에 있어서, 하나의 SPE(206)는 디아카이버가 다른 SPE와 복원화 과정을 수행하도록 요청할 수 있다. 이는 일례로 원격 프로시저 호출(remote procedure call; RPC)를 사용하여 프로세서들 사이에서 구현될 수 있다. 이번 예에 있어서, SPE(206)는 PPE(204)에게 이를 위해 무엇인가를 하도록 요청한다. 더 통상적인 RPC에서는, 반대로 수행된다.
어떠한 실시예들에 있어서, 스케줄러 캐시(305)(예. HDD 캐시)는 미디어 장치에서의 파일을 저장 장치(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 요청들에게 방해되지 않을 때에 실행될 것이다. 예를 들어, 시스템(300)은 느린 미디어 장치(118)(예. 블루 레이 디스크(BD) 드라이브와 같은 광 디스크)와 하드 디스크 드라이브와 같은 비교적 고속 기억장치(115)를 가진다. 스케줄러 캐시 계층(305)은 광 디스크 드라이브에서 하드 디스크로 파일을 비동기식으로 카피하는데 사용될 수 있다. 나중에 파일이 접속될 때 이 파일은 비교적 느린 광 디스크 속도(예. 8 MiB/s) 대신, 보다 더 높은 HDD속도(예. 20 MiB/s)로 판독될 것이다.
캐시 프리페치(pre-fetch) 과정은 보통 하드 디스크 캐시에서 수행되지만, 프리페치(pre-fetch) 과정은 메인 메모리(106, 206)에서도 수행될 수 있다. 프리페치(pre-fetch) 요청들은 스케줄 큐(406)의 마지막 부분에 포함될 수 있는데, 이 때 프리페치(pre-fetch) 요청들은 스케줄 과정 완료 후 수신된 순서에 따라 포함될 수 있다. 어떠한 실시예들에 있어서, 프리페치(pre-fetch) 요청들은 필요 시 지연될 수 있다.
소정의 실시예들에서, 스케줄러(302)에 의해 사용되는 성능 특징 수학식은 상태 정보의 일부로 무엇이 캐시(117)에 저장되었는지에 관한 정보를 포함할 수 있다. 프리페치(pre-fetch) 작업들은 다른 I/O 작업들과 동일한 방식으로 스케줄링 되지 않는다. 프리페치(pre-fetch) 작업들은 스케줄 큐(406)가 빈(empty) 경우에만 운용되는, 분리된 프리페치(pre-fetch) 큐(413)에 수용된다. 프리페치(pre-fetch) 작업은 필요 시 지연될 수 있다. 그렇지 않으면, 프리페치(pre-fetch)들은 수신된 순서에 따라 처리될 수 있다. 스케줄러(302)는 프리페치(pre-fetch) 요청들을 큐 내에 보유하다가 특정 시간 동안 I/O 서브시스템이 대기 중일 때만 실행할 수 있다. 이는 프리페치(pre-fetch) 요청들이 보통의 I/O 요청들을 방해하지 않도록 한다. 또한, 프리페치(pre-fetch) 요청들은 단일의 캐시 블록으로 제한되지 않으며, 그들은 어떠한 크기나 캐시가 파일 처음부터 끝까지, 파일 전체를 로드하도록 지시하는, 파일 전체 값의 크기도 가질 수 있다. 이에 더하여 프리페치(pre-fetch) 요청들이 어떠한 크기도 될 수 있지만, 프리페치(pre-fetch)들은 FIOS 스택(300)이 지속적으로 대기 상태에 있는 지 체크하기 위해서 스케줄러(302)로 리턴하기 전에, 하나의 캐시 블록 까지만 채우도록 구현될 수 있다.
FIOS 스택(300)은 불필요한 프리 페치들을 피하는 방향으로 프리페치 과정을 구현하도록 설정될 수 있다. 예를 들면 도 6에 도시된 바와 같이, 캐시(601) 안에 어떠한 블록도 없으면, FIOS 스케줄러 캐시 계층(305)는 첫 번째 블록을 채우고, 그런 다음 대기 상태를 확인하기 위해 리턴할 수 있다. 만약 제 1 내지 제 N 블록들이 저장부(115) 속 캐시(117) 내에 있으면, N+1 번째 블록이 미디어 장치(118)으로부터의 데이터로 채워질 것이다. 스케줄러 캐시 계층(305)은 대기 상태를 확인하기 위해 리턴할 수 있다. 이와 같은 공정은 새로운 IO가 인커밍 큐에 도착할 때까지 반복될 수 있다. 이러한 특징들은 임의의 수의 프리 페치 과정들이 대기하도록 하여서, 스케줄 된 통상의 IO 요청들을 방해하지 않고도 미디어 장치(118)에서 저장부(115)(또는 메인 메모리(106))로 대용량 데이터를 프리 페치하는 어플리케이션이 빠르고 효율적일 수 있도록 한다.
예를 들면, 게임 어플리케이션에서, 게임 데이터는 주로 미디어 장치(118)에 의해 판독되는 CD-ROM 이나 HD-DVD 디스크와 같은 매체에 저장된다. 게임은 플레이어가 특정 목적지를 향해 움직이는 것을 판단하고, 플레이어가 그곳에 60초 이내에 도착해야 하는 것으로 연산할 수 있다. 이 시간 동안 FIOS 스택(300)은 미디어 장치에서 목적지에 연계하여 프리 페치할 수 있다. 어플리케이션은 플레이어가 회전해서 머리가 다른 목적지로 향하면, 프리 페치 과정을 취소할 수 있다. 다른 실시예들에 있어서, 어플리케이션은 캐시(117)에 있는 필요한 데이터가 오버라이트 되지 않도록 사전 통지를 사용할 수 있다.
상술된 캐시 프리페치(pre-fetch) 과정은 비디오 게임과 같이 I/O 기반(driven) 어플리케이션들에서와 현재 비디오 게임 콘솔과 같이 특정 I/O 필요성을 가진 플랫폼들에서 증진된 I/O 성능을 제공할 수 있다. 특히 게임 데이터는 광학 매체나 네트워크 파일 서버와 같이 느린 매체에 주로 저장되지만, 게임은 HDD와 같이 빠른 로컬 저장부에 접속할 수 있다.
<보조 프로세서로 데이터 변환하는 과정>
다른 실시예에 따르면, FIOS는 메인 프로세서와 연계된 로컬 메모리를 구비한 보조 프로세서를 활용하는 특정 프로세서 구조를 이용한다. 이러한 실시예들은 일례로, 복원 과정이나 복호화 과정과 같은 데이터 변환 과정들을 위해 사용될 수 있다. 비교하자면, 특정 종래 디아카이브 시스템들 표준 배경 스레드(standard background thread)에서 실행되는 단순한 복원 알고리즘(zlib과 같은)을 사용하였다. 이에 반해 본 발명의 실시예들은 표준 복호기 구현과 셀 프로세서 구조와 같이 연계된 로컬 메모리를 구비한 보조 프로세서를 갖춘 프로세서 구조들을 이용하도록 설정된 비표준 구현을 가능케하는 앱스트랙트 코덱 인터페이스(abstract codec interface)를 포함할 수 있다. 이러한 실시예들은 많은 플래그들과 제약들이 복원기 물체(decompressor object)에 의해 설정되도록 한다. 이에 따라 디아카이버(301)는 이러한 것들을 메모리 사용과 속도를 최적화하는데 이용할 수 있다. 이러한 제약들과 상황들의 많은 경우는 게임 프로그래밍 상황들, 파일 시스템 I/O 복원화 또는 시스템(100)의 구조에 대하여 유일하게 특별한 처리 방법을 초래한다.
비디오 게임 어플리케이션과 같은 특정 어플리케이션들은 제한된, 가용한 메모리 용량을 가진다. 따라서 이와 같은 어플리케이션들은 가능한 적은 양의 메모리를 사용하고자 한다. 이들은 공통적으로 I/O 복원화를 위하여 단 세 개의 I/O 버퍼들을 가진다. 하나의 버퍼는 판독 작업이 차지하고, 두 개 까지의 임시 버퍼들(하나는 입력용, 다른 하나는 출력용임)은 데이터 변환 작업(예. 복원화나 복호화)이 차지한다. 이로 한정되지 않지만 예를 들자면, 특정 실시예들은 데이터 변환 작업들을 위해, 연계된 로컬 메모리를 구비한 보조 프로세서(예. 셀 프로세서(200) 내 SPE(206))를 사용함으로써, 임시 버퍼들 전체를 사용하는 것을 피할 수 있다.
예를 들어 복원 과정이 메인 프로세서(예. PPE(204))에 의해 처리된다면, 압축된 데이터를 임시 저장하는데 보통 하나의 버퍼가 요구되고 복원된 데이터를 임시 저장하는데 다른 하나의 버퍼가 요구된다. 만약 충분한 로컬 메모리(106B)를 구비한 보조 프로세서(105B)가 가용하면, 동일한 복원화 과정이 임시 버퍼들 대신에 로컬 메모리(106B)를 사용하여 수행될 수 있다. 압축된 데이터와 복원된 데이터 모두는 로컬 메모리(106B)에 저장될 수 있다. 예를 들면 특정 셀 프로세서 구조들에 있어서, SPE(205)는 256 킬로바이트의 로컬 저장 용량을 가진다. 이는 압축된 입력, 복원된 출력, 그리고 복원 알고리즘 코드를 저장하기에는 통상적으로 충분한 메모리 공간이다. 이에 비해 복원화 과정이 메인 프로세서(105A)(예. PPE(204)에 의해 처리되면, 압축된 데이터는 제 1 버퍼에서 읽혀지고 복원되며, 복원된 데이터는 제 2 버퍼에 기록된다. 복원된 데이터는 제 2 버퍼에서 그의 목적지로 카피된다.
도 7a 및 도 7b는 보조 프로세서를 활용하는 특정 데이터 변환 과정을 구현하는 다른 예들 중 두 개의 예를 도시한다. 특히 도 7a에 도시된 바와 같이, I/O 요청을 실행하는 동안, 메인 프로세서9105A)에서 운용되는 FIOS(300)는 데이터 변환 계층(311)을 통해 데이터 변환을 인보크(invoke)할 수 있다. 메인 프로세서(105A)는 702 과정에 도시된 바와 같이 보조 프로세서(105B)를 설정할 수 있다. 구체적으로 메인 프로세서(105A)는 보조 프로세서(105B)가 데이터 변환 과정이 보조 프로세서의 로컬 메모리(106B)에서 구현되도록 하는, 코딩된 인스트럭션들(701)을 로딩하게끔 지시할 수 있다. 그런 다음 메인 프로세서나 보조 프로세서는 704 과정에 표시된 바와 같이 데이터(703)를 미디어 장치(118)에서 메인 메모리(106)로 전송하기 위해 FIOS 스택(300)을 처리해나갈 수 있다. 그런 다음 706 과정에 표시된 바와 같이 보조 프로세서(105B)는 데이터(703)를 로컬 메모리(106B)에 로딩할 수 있다.
그 후 보조 프로세서는 708 과정에 표시된 바와 같이 변환된 데이터(705)를 생성하기 위해 데이터(703)에서의 변환을 구현할 수 있다. 예를 들면, 코딩된 인스트럭션들(701)의 실행 과정은 데이터(703)를 복호화하거나 복원할 수 있다. 변환된 데이터(705)는 710 과정에 표시된 바와 같이 메인 메모리(106)로 전송될 수 있다. 선택적으로 변환된 데이터(705)는 저장부(115)와 같은 다른 목적지로 전송될 수 있다. 앞서 말한 일련의 과정들은 I/O 요청에 의해 특정된 모든 데이터가 처리될 때까지 잇따른 데이터 블록들에 대하여 반복될 수 있다. 참고로 인커밍 데이터(703)가 로컬 메모리(106B)로 전송되고 나면, 메인 메모리에서는 새로운 인커밍 데이터나 변환된 데이터로 오버라이트(overwrite) 될 수 있다.
이로 한정되지 않지만 예를 들면, 도 2에 도시된 것과 같은 셀 프로세서 구조는 도 7a에 따른 데이터 복원 과정을 구현하는데 사용될 수 있다. 본래 SPU 프로그래밍(데이터가 SPE(206)의 로컬 저장부(LS)로 스트리밍 되고, 그 다음 처리가 완료된 후 다시 스트리밍 되어 나오는)은 파일 시스템 I/O 복원 과정의 요청들과 함께 조합되서 I/O 성능이 향상될 수 있는 기회를 제공한다. 예를 들면, 복원 과정에서 SPE(206)를 사용하여 37 Mbps에서 42 Mbps로 향상된 성능을 제공할 수 있다. 이는 버퍼가 추가로 사용되지 않기 때문이다. 이와 비슷한 복원화 과정은 소니 플레이스테이션 2에서 사용되는 프로세서 구조와 함께 구현될 수 있다. 이러한 경우 메인 프로세서는 이모션 엔진(emotion engine; EE)으로 지칭되고, 보조 프로세서들 중 I/O 프로세서(IOP)로 알려진 하나는 연계된 로컬 메모리를 구비한다. 이와 같은 경우, 디아카이버(301)는 EE에서 구동되고, 복원 과정은 도 7a에 도시된 선들을 따라 IOP에서 구현될 수 있다. 선택적으로, 도 7a에 도시된 기술은 개별적으로 접근 가능한 메모리들(separately addressable memories)을 가진 두 개의 프로세서들을 포함하는 분산 연산 구조들(distributed computing architecture)을 위하여 사용될 수 있다.
참고로 전술된 예는 변환 계층에 의해 구현되는 데이터 변환 과정에 관한 것이지만, 도 7a를 참조하여 서술된 방법은 미디어 필터 계층들(304) 중 어느 하나를 구현하는데 사용될 수 있다. 이에 반해 종래 파일 I/O 시스템들은 주로 메인 프로세서(예. 셀 프로세서 예에서의 PPU)로 구현한다.
선택적인 구현예에 있어서, 미디어 장치(118)에서 판독된 데이터의 목적지가 느린 메모리(예. 영상 램(VRAM)과 같은 그래픽 메모리(140))이고 코덱이 그의 출력 정보를 임의 접근해야한다면, FIOS 디아카이버가 임시 출력 버퍼를 할당할 필요가 발생할 수 있다. 한편 코덱이 임의 접근할 필요가 없는 경우(예. SPU에서 구현되는 복원기를 구비한 경우), FIOS 디아카이버(301)는 임시 출력 버퍼를 할당하는 것을 피하고 데이터(703)는 곧바로 목적지에서 복원될 수 있다. 게다가 파일 시스템 복원 과정은 '슬롭(slop)' 또는 미사용된 바이트들을 필요로 할 수 있다. 즉 소정의 바이트들만 필요할 때 64 킬로바이트 블록 전체를 복원할 수 있다. 코덱이 그가 압축된 블록의 일부만 출력할 수 있는 것으로 표시하면(예. SPU에서 구현되는 복원기를 구비한 경우), FIOS 디아카이버는 임시 출력 버퍼를 할당하는 것을 피할 수 있다. 또한 연계된 로컬 메모리(106B)를 구비한 보조 프로세서(105B)는 상술된 상황들의 일부 또는 전체의 조합에서 사용될 수 있다.
도 7b는 느린 그래픽 메모리(340)과 함께 구동되는 보조 프로세서(105B)와 로컬 메모리(106B)의 사용예를 도시한다. FIOS(300)는 미디어 장치(118)로부터의 데이터를 그래픽 메모리(340)(예. VRAM)에 판독한다. 버퍼들을 사용하는 VRAM으로의 데이터 전송은 보통 느리다. 그러나 VRAM 데이터를 특정 종류의 보조 프로세서 로컬 메모리들(예. SPE(206)의 로컬 저장부(LS))에서 판독하는 것은 문제가 되지 않는다. 도 7b에 도시되는 예에서 FIOS(300)는 주로 메인 프로세서(105A)에서 구현된다. 변환되지 않은 데이터(703)는 그래픽 메모리(340)에서 보조 프로세서(105B)와 연계된 로컬 메모리(106B)로 전송될 수 있다. FIOS(301)는 변환 인스트럭션들(701)을 로컬 메모리(106B)에서 로딩하여 보조 프로세서(105B)에 의해 실행되도록 할 수 있다. 보조 프로세서(105B)는 변환된 데이터(705)를 생성하기 위한 인스트럭션들(701)을 실행함으로써, 데이터(703)를 변환된 데이터로 변환할 수 있다. 그런 다음 변환된 데이터는 그래픽 메모리(340)로 전송된다. 본 실시예의 변형물들에서는 변환되지 않은(예. 부호화되거나 압축된) 데이터(703)는 미디어 장치(118)에서 판독되고 로컬 메모리(106B)로 전송되기 전에 메인 메모리(106)에 있는 버퍼에 저장될 수 있다.
<네스팅 된 아카이브들(nested archives)>
종래의 FIOS 구현물들은 압축된 아카이브의 콘텐츠가 파일 시스템 계층 구조(hierarchy)에 가상으로 나타도록 하는 임의 접근 디아카이브 시스템을 구비하였다. 또한 임의 접근 디아카이브 시스템은 판독 과정과 복원 과정을 오버랩(overlap)함으로써, 아카이브들에서 최적한 효율적인 방법으로 데이터를 추출하였다. 본 발명의 실시예들은 단일의 디아카이버 계층(301)으로 네스팅 된 아카이브들을 처리하는 능력을 포함하고 성능 저하에 따른 패널티가 없도록(no performance penalty) 함으로써, 이러한 시스템을 개선한다. 본 명세서에서의 '네스팅 된 아카이브들'이라는 용어는 다른 아카이브들, 즉 그들 조차 임의의 네스팅 심도 레벨까지로 다른 아카이브 안에 저장된, 내에 저장된 아카이브들을 지칭한다.
네스팅 된 아카이브를 지원하는 것은 게임 I/O와 데이터 레이아웃(data layout)의 특별한 요청들을 만족시키는데 특히 유용하다. 네스팅 된 아카이브들의 사용은 스케줄러(302)에 의해 사용되는 드라이브 모델(drive model)(302A)과의 상승효과를(synergistic with) 가질 수 있다. 구체적으로 대용량 파일들은 드라이브 헤드 움직임에 대한 더 나은 모델을 허용한다. 네스팅 된 아카이브를 지원하는 것은 압축된 아카이브 포맷이 임의 접근식이면 매우 용이하게 될 수 있다. 이에 반해, 압축된 아카이브들은 주로 임의 접근식이 아니다. 예를 들면, zip, gzip, 7z 등의 압축 포맷들은 아카이브 초반부터 주로 선형적 접근식(linear access)을 요구한다. 본 명세서에서 사용되는 '아카이브(archive)'라는 용어는 단일의 더 큰 파일로 조합되는 데이터 파일들의 일군을 지칭한다. 소스 데이터는 미변경 상태로 저장되거나, 압축 또는 복호화와 같은 하나 이상의 데이터 변형 과정들이 데이터의 일부분에 적용될 수 있다. 인덱스(종종 목차(table of content)로 지칭되는)는 아카이브 내 경로와 오프셋(offset)과 같은 소스 파일들의 적어도 일부 양면을 설명하는 아카이브와 함께 보유되어서, 그들이 룩업(look up)되고 각각 접속될 수 있다. '네스팅 된 아카이브'라는 용어는 하나 이상의 소스 파일들이 다른 아카이브( 또는 네스팅 된 아카이브) 내에 있는 아카이브를 가리킨다. 이러한 네스팅 덕분에 주어진 어떠한 소스 데이터 블록에도 제로 이상의 데이터 변환 과정이 적용될 수 있다. 예를 들면, 두 개의 레벨(레벨 1, 레벨 2)을 가진 비디오 게임 어플리케이션은 "game.psarc"라는 제목을 가지고, "level1.psarc" 및 "level2.psarc"의 제목을 가진 두 개의 아카이브들을 포함하는 네스팅된 아카이브를 사용할 수 있다. 이는 게임 개발자들이 더 큰 용량의"game.psarc" 아카이브를 매번 생성하는데 시간을 소비하는 대신, 디버그 및 테스트 목적으로 단일의 아카이브들("level1.psarc", "level2.psarc", 등)을 사용하도록 함으로써, 개발을 용이하게 한다.
개발자들은 네스팅 된 아카이브들을 생성할 수 있지만, 통상적인 I/O 리더는 다중 레벨 아카이브들을 판독할 수 없거나 효율적으로 판독할 수 없다. 이를 극복하기 위하여, 아카이브는 도 8에 도시된 바와 같이 설정될 수 있다. 특히 외부 아카이브(outer archive)(800)는 게임의 각 레벨들을 위한 데이터를 가진 파일들을 포함하는 내부 아카이브들(inner archives)(801, 802)을 내포할 수 있다. 이로 국한되지 않지만 예를 들자면, 내부 아카이브들(801, 802)은 지도, 그 레벨에서 사용 가능한 무기 및 그 레벨에서 맞서야하는 적들과 같은 특정 게임 레벨과 관련된 데이터를 포함할 수 있다. 내부 아카이브들(801, 802)의 데이터는 각각 압축되고, 공통 데이터(803)로 묶일 수(bundled) 있다. 외부 아카이브(800) 내 파일들은 블록 별로 압축될 수 있다. 아카이브들 각각은 디아카이버가 내부 아카이브들(801, 802)의 어느 장소도 포함하는 외부 아카이브(800) 내 어디에 있는 주어진 어떠한 데이터 블록을 찾도록 하는 인덱스를 포함할 수 있다. 인덱스는 아카이브에 대한 목차의 균등물로 취급될 수 있다.
FIOS(300)이 아카이브에서의 특정 파일에 대한 요청을 발행할 때 요청은 하기와 같이 보일 수 있다.
Request: /game/level2/map(1000,10)
특정 파일을 찾는데 사용되는 "/game/level2/map" 부분은 경로를 가리킨다. "(1000,10)" 부분은 요청의 오프셋과 길이를 식별한다. 외부 아카이브(800) 또는 그 일부가 판독될 때 디아카이버(301)는 가용한 파일들의 리스트를 고려할 수 있다. 리스트는 열려진 아카이브들에 따라 다를 수 있다. 예를 들면 외부 아카이브(800)나 내부 아카이브들(801, 802) 중 어느 것도 열리지 않은 경우의 리스트는 하기와 같다.
/game.psarc
만약 외부 아카이브(800)가 열리면, 리스트는 하기와 같다.
/game (folder)
/game/level1.psarc
/game/level2.psarc
/game/common.dat
내부 아카이브들이 열린 경우의 리스트는 하기와 같다.
/game/level1/map
/game/level1/weapons
/game/level1/enemies
/game/level2/map
/game/level2/weapons
/game/level2/enemies
/game/common.dat
아카이브들(800, 801, 802) 각각은 콘텐츠 경로(또는 경로의 일부)의 해시들 리스트(list of hashes)를 가질 수 있다. 해시 리스트는 아카이브의 목차(TOC)를 생성하는데 사용될 수 있다. 예를 들면, 외부 아카이브(800)에 대한 목차는 하기와 같이 설정될 수 있다.
TOC:
hash (/level1.psarc)
hash (/level2.psarc)
hash (/common.dat)
'hash()'는 괄호 안의 양(quantity)의 해시를 가리킨다. MD5 해시(MD5 hash)와 같은 어떠한 적합한 해시도 사용될 수 있다.
이와 같이 레벨 1 내부 아카이브(801)에 대한 목차는 하기와 같이 설정될 수 있다.
TOC:
hash(/map)
hash(/weapons)
hash(/enemies)
도 8에 도시된 바와 같은 종류의 네스팅 된 아카이브들이 사용되면, 디아카이버(311)는 이들을 취급하도록 설정될 수 있다. 예를 들면, 디아카이버(311)는 도 9에 도시된 바와 같은 디아카이브 방법(900)을 구현할 수 있다. 이러한 방법(900)은 902 과정에 표시된 바와 같이 아카이브에서 초기 룩업(initial lookup)을 수행할 수 있다. 이로 제한되지 않지만 예를 들면, 초기 룩업은 찾고자 하는 데이터에 대한 초기 경로, 오프셋, 길이 및 요구되는 데이터 변환 과정들의 순서 리스트를 리턴(return)할 수 있다. 구체적으로 I/O 요청은 하기와 같을 수 있다.
(/game/level2/weapons, offset 0, length 50000, none)
내부 아카이브 내 이 파일의 초기 룩업은 하기와 같은 결과를 리턴할 수 있다.
(/game/level2.psarc, offset 20000, length 30000, zlib decompress)
초기 룩업 후, 디아카이버(311)는 904 과정에 표시된 바와 같이 네스팅을 분해(resolve)할 수 있다. 네스팅을 분해하는 과정에서 디아카이버(311)는 아카이브(802)가 다른 아카이브 내에 있는지, 그리고 압축되거나 압축 해제된 상태로 저장되어 있는지 판단하려 할 수 있다.
네스팅을 분해하는 과정에서 디아카이버(311)는 찾고자 하는 데이터에 대한 초기 경로, 오프셋, 길이 및 요구되는 데이터 변환 과정들의 순서 리스트를 리턴할 수 있다. 예를 들면, 경로는 "/game.psarc, offset 120000, length 30016, decrypt + zlib decompress"와 같을 수 있다. 네스팅은 스택의 한계를 넘지 않기 위해 재귀(recursion) 보다는 루프(loop)로 분해될 수 있다. 한번 네스팅이 분해되고 나면, 데이터는 미디어 장치(118)에서 전송될 수 있다. 이에 한정되지 않지만 예를 들면, 디아카이버(311)는 905 과정에 표시된 바와 같이 데이터를 블록마다(block by block) 반복적으로 판독 및 변환할 수 있다. 특히 디아카이버(311)는 906 과정에 표시된 바와 같이 데이터 블록을 판독할 수 있다. 그런 다음 디아카이버(311)는 908 과정에 표시된 바와 같이 판독된 블록에 데이터 변환 과정을 적용할 수 있다. 다중 레벨을 가진 네스팅 된 아카이브들은 가장 외부의 아카이브부터 판독해서 단일의 인터리브 된(interleaved) 판독 및 변환 루프까지 분해될 수 있다. 이는 소스 미디오의 효율적인 사용을 극대화한다. 각각의 블록들이 판독되고 변환된 후에는, 910 과정에서 표시되는 바와 같이 원하는 부분이 메인 메모리(106)나 저장부(115)나 다른 어느 곳의 적합한 목적지로 카피될 수 있다. 원하는 블록의 일부의 크기는 작게는 하나의 바이트, 크게는 블록 전체 등의 어떠한 크기이든 가능하다.
<오버레이 계층(overlay layer)>
상술된 바와 같이 FIOS 스택(300) 내 미디어 필터 계층(304)은 오버레이 계층(307)을 포함할 수 있다. 본 발명의 한 실시예에 따르면, 오버레이 계층(307)은 파일 시스템 레벨에 있는 파일들과 디렉터리들을 임의로 오버레이 하도록 설정될 수 있다. 일반적인 개념은 유닉스(Unix)의 유니온 마운트(union mount)와 비교될 수 있지만, 이것은 훨씬 더 유연한다. 통상적인 유니온 마운트는 하나의 파일 시스템 내에 있는 디렉터리를 다른 파일 시스템 전체 콘텐츠들과 합친다. 오버레이 계층(307)은 이와 비슷하지만 훨씬 더 유연하고 더 많은 특징들(full-featured)을 가진다. 예를 들면, 오버레이 계층(307)은 디렉터리, 파일 또는 파일들 내 바이트 범위들까지의 입도(granularity; 粒度)에서 동작한다. 디렉터리들은 숨겨져 있거나 그들의 콘텐츠들은 오버레이 계층(307)을 사용해서 대체될 수 있다. 또한 오버레이 계층(307)은 주 데이터 소스에서 요청된 파일들을 부수적인 데이터 소스로부터의 다른 파일들로 대체하는데 사용될 수 있다. 부수적인 데이터 소스는 주 데이터 소스와 같은 매체에 있거나 다른 매체에 있는 파일이나 디렉터리가 될 수 있다. 또한 부수적인 데이터 소스는 가상 데이터 소스가 될 수 있어서, 데이터가 콜백(callback)에 의해 특정될 수 있다. 이러한 특정 맥락에서의 '콜백'이라는 용어는 다른 코드로 인수(argument)로 패스되는 실행가능한 코드를 의미한다.
이에 더하여, 오버레이를 생성하는 어플리케이션은 어떻게 그리고 언제 오버레이가 오버레이 계층(307)에 적용될 수 있다는 조건을 특정할 수 있다. 예를 들어 어플리케이션(103)이 디렉터리 B를 디렉터리 A로 오버레이하는 경우, 조건은 하기와 같을 수 있다.
"overlay": B 에서 파일들을 먼저 찾고, 그 다음 A 에서 찾음,
"underlay": A에서 파일들을 먼저 찾고, 그 다음 B에서 찾음,
"newer": 만약 파일이 두 장소 모두에 존재하는 경우, 가장 최근 변경 날짜를 가진 파일 사용,
"older": 만약 파일이 두 장소 모두에 존재하는 경우, 더 이른 변경 날짜를 가진 파일 사용, 등.
오버레이 계층(307)은 특정 소스에서 I/O 판독 작업에 대한 요청들과 다른 소스에서 판독하는 작업을 임의로 매핑할 수 있도록 한다. 예를 들면, 미디 장치(118)에서 특정 파일을 판독하는 요청은 일례로 저장부(115)에 위치한 대응하는 파일에 매핑될 수 있다. 이러한 특징을 사용하여, 파일 내 소정의 바이트들에서부터 전체 디렉터리들까지의 데이터가 숨겨질 수 있고, 바뀔 수 있다(swapped around). 어떤 디렉터리들에 있는 파일들이나 바이트들이 대체되어야하는지 특정지음으로써, 오버레이 계층(307)은 특정 I/O 요청을 처리하기 위해 FIOS 스택(300)이 수행해야하는 작업량을 최소화할 수 있다.
오버레이 계층(307)은 일례로, 소프트웨어 및/또는 데이터의 업데이트들을 구현하는데 사용될 수 있다. 많은 종래의 업데이트 시스템들에 있어서, 실행가능 및 링크가능 파일(executable and linkable file; ELF)는 미디어 장치(118)에서 저장부(115)로 카피되고, 업데이트 된 코드나 데이터로 패치된다(patched). 이에 반해 본 발명의 실시예들은 어플리케이션(103)이 FIOs(101)이 특정 바이트 범위를 미디어 장치(118)로부터의 데이터와 저장부(115)와 같은 소정의 다른 위치로부터의 다른 바이트 범위들로 채우도록 지시할 수 있다. 따라서 패치 작업을 하기 위하여 파일 전체를 카피할 필요가 없다. 대신 패치 과정은 I/O 시스템 레벨에서 구현될 수 있다.
가장 최근의 종래 패치 구현물들은 파일들 전체를 대채하는 구성에 기초한다. 이는 구현하기에 가장 단순하고 이에 여태껏 가장 많이 사용되는 방법이다. 이에 반해 더 복잡하고 압축되고 복호화된 아카이브 내 패치 과정과 같이 유용한 패턴들을 허용하는, 향상된 패치 방법은 오버레이 계층(307)에 의해 구현될 수 있다.
<스피드 에뮬레이션 계층(speed emulation layer)>
본 발명의 특정 실시예들에 있어서, 스피드 에뮬레이션 계층(315)은 더 느린 I/O 장치의 성능을 에뮬레이션 하기 위한 개발(development) 중 고속 기억장치의 속도를 줄이는데 사용될 수 있다. 스피드 에뮬레이션 계층(315)은 더 느린 I/O 장치의 탐색 시간(seek time), 처리량(throughput) 및 다른 성능 특징들의 모델을 활용할 수 있다. 예를 들면, 스피드 에뮬레이션 계층(315)은 저장부(115)(일례로, 하드 디스크 드라이브)의 속도로 낮춰서 미디어 장치(118)(예. 블루 레이 드라이브와 같은 HD-DVD)의 더 느린 탐색 시간 및/또는 처리량을 에뮬레이션 할 수 있게 한다.
본 발명의 실시예에 따르면, 스피드 에뮬레이션 계층(315)은 이전 세션 동안 수집된 드라이브 성능 데이터를 다음 세션들에 공급하여 구현될 수 있다. 상술된 바와 같이, 스케줄러(302)에 의해 사용되는 성능 모델은 처리량, 레이저의 흔들림(wiggles), 판독 헤드의 움직임, 레이어 변경 및 요청 오버헤드까지, 복잡한 드라이브 특징들을 임의로 모델링하도록 설정될 수 있다. 스피드 에뮬레이션 계층(315)은 이러한 정보를 사용하여 상당히 높은 정확성을 가진, 특정 미디어 장치의 에뮬레이션을 제공할 수 있다. 런타임 성능(runtime performance)에 기초하였기 때문에, 이러한 에뮬레이션은 탐색 시간과 같이 더 복잡한 상세 특징들을 무시하고 간단하게 처리량만 매치하려 하는 단순한 에뮬레이션 계층들보다 더 높은 정확성을 제공할 것이다.
본 발명의 실시예들은 상당수의 I/O를 이용하는 어플리케이션 및 시스템들에서의 증진된 I/O 성능을 제공한다. 상술된 바와 같이 본 발명의 실시예들은 비디오 게임 어플리케이션들과 비디오 게임 시스템들에서 특히 유용하다. 그러나 본 발명의 실시예들은 이러한 어플리케이션들과 시스템들에 국한되지 않는다.
상기의 상세한 설명은 본 발명의 바람직한 실시예의 온전한 설명이지만, 다른 균등물과 변형들이 사용될 수 있다. 그러므로, 본 발명의 범위는 상기 설명을 참조하여 판단되지 말아야 하며, 대신, 첨부된 청구항들과 그 균등물들의 모든 범위를 함께 참조해서 판단되어야한다. 본 명세서에 서술된 어떠한 기술적 특징도, 본 명세서에 서술된 다른 어떠한 기술적 특징과 바람직하게든 아니든 결합될 수 있다. 첨부된 청구항들에 "~을 위한 수단(means for)"의 기재가 명시적으로 사용되지 않은 이상, 수단 또는 과정으로 해석되어서는 안 된다.

Claims (43)

  1. 프로세서부, 메모리 및 미디어 장치를 구비한 시스템에 있어서, 상기 프로세서부는, 메인 프로세서와, 연계된 로컬 메모리를 구비한 보조 프로세서를 포함하고, 상기 미디어 장치와 왕복적으로 입출력(input or output; I/O)하는 과정을 처리하기 위한 방법으로,
    a) 상기 미디어 장치와 왕복적으로 데이터를 전달하기 위해 상기 프로세서에서 실행되는 어플리케이션(application)으로부터의 인커밍(incoming) I/O 요청을 수신하는 과정과,
    b) 상기 인커밍 I/O 요청을 완료하기 위한 예상 시간(TP)을 연산하는 과정과,
    c) 상기 메모리에 내장된 스케줄에 상기 인커밍 I/O 요청을 삽입하는 과정과,
    d) 상기 스케줄에 따라 상기 인커밍 I/O 요청을 수행(service)하는 과정을 포함하고,
    상기 인커밍 I/O 요청은, 상기 미디어 장치에서 상기 로컬 메모리로 데이터를 전달하고, 상기 보조 프로세서를 사용하여 상기 로컬 메모리 내 상기 데이터를 변환함으로써 수행되고,
    상기 인커밍 I/O 요청이 수행되기 이전에 수신된 상기 스케줄 내의 상기 인커밍 I/O 요청의 다음 차례(subsequent) I/O 요청은, 상기 인커밍 I/O 요청이 완전히 다 수행된 이후에 수행되며,
    상기 스케줄 내에 있는 상기 인커밍 I/O 요청의 위치는,
    적어도 부분적으로 상기 예상 시간(TP)에 의존하는 것을 특징으로 하는 방법.
  2. 제 1항에 있어서,
    상기 b) 과정은, 상기 미디어 장치의 하나 이상의 파라미터와 상기 인커밍 I/O 요청으로부터 판단되는 하나 이상의 계수(coefficient)를 포함하는 성능 특징 수학식(performance characteristic equation; PCE)에 따라 TP를 산출하는 과정을 포함하는 것을 특징으로 하는 방법.
  3. 제 2항에 있어서,
    상기 하나 이상의 파라미터는, 요청 오버헤드 x(request overhead x), 헤드 움직임 속도 y(head movement rate y) 및 처리량 z (throughput z)를 포함하는 것을 특징으로 하는 방법.
  4. 제 3항에 있어서,
    상기 하나 이상의 계수는, 오버헤드 계수 A(overhead coefficient A), 헤드 이동 거리 B(head travel distance B) 및 전송할 데이터 용량 C(amount of data to transfer C)를 포함하는 것을 특징으로 하는 방법.
  5. 제 4항에 있어서,
    상기 특징 수학식은, TP = Ax + By + Cz 인 것을 특징으로 하는 방법.
  6. 제 2항에 있어서,
    상기 c) 과정은,
    상기 스케줄 내 복수의 다른 I/O 요청들에 대한 다른 계수들을 사용하여 상기 PCE를 반복 계산하여, 상기 I/O 요청들을 수행하기 위한 총 시간(T)를 판단하는 과정을 포함하는 것을 특징으로 하는 방법.
  7. 제 6항에 있어서,
    상기 c) 과정은,
    상기 복수의 I/O 요청들의 두 개 이상의 다른 순서들에 대한 상기 총 시간(T)의 두 개 이상의 다른 값들을 연산하는 과정과,
    상기 총 시간(T)의 최적 값에 기초하여 상기 인커밍 I/O 요청을 상기 스케줄에 삽입하는 과정을 더 포함하는 것을 특징으로 하는 방법.
  8. 제 7항에 있어서,
    상기 총 시간(T)의 상기 최적 값은, 상기 복수의 I/O 요청들의 상기 두 개 이상의 다른 순서들에 대한 상기 총 시간(T)의 최소 값인 것을 특징으로 하는 방법.
  9. 제 2항에 있어서,
    상기 b) 과정은, I/O 요청을 수행하는 실제 시간(Ta)을 측정해서, 상기 하나 이상의 계수와 함께 하나 이상의 미지의 파라미터(unknown parameter) 값을 위하여 상기 PCE를 반복적으로 푸는(solve) 과정을 포함하는 것을 특징으로 하는 방법.
  10. 제 1항에 있어서,
    상기 d) 과정은, 압축되고 네스팅 된 아카이브(compressed nested archive)에서의 특정 데이터를 추출하는 과정을 더 포함하는 것을 특징으로 하는 방법.
  11. 제 1항에 있어서,
    상기 시스템은, 그래픽 프로세서와 연계된 그래픽 메모리를 더 포함하고,
    상기 d) 과정은,
    상기 미디어 장치로부터의 데이터를 상기 그래픽 메모리에서 판독하는 과정과,
    상기 그래픽 메모리로부터의 상기 데이터를 상기 로컬 메모리로 전송하는 과정과,
    변환된 데이터를 생성하기 위해 상기 보조 프로세서를 사용하여 상기 데이터에 데이터 변환 과정을 수행하는 과정과,
    상기 변환된 데이터를 다시 상기 그래픽 메모리로 전송하는 과정을 포함하는 것을 특징으로 하는 방법.
  12. 제 1항에 있어서,
    상기 d) 과정은, 데이터 오버레이 과정을 구현하는 과정을 포함하고,
    상기 미디어 장치와 상기 메모리 사이에서 전송되는 하나 이상의 주 데이터 유닛들은, 제 2 데이터 소스로부터의 하나 이상의 제 2 데이터 유닛로 대체되는 것을 특징으로 하는 방법.
  13. 제 12항에 있어서,
    상기 주 데이터 유닛들의 소스와 상기 제 2 데이터 소스는, 동일한 미디어에 위치한 것을 특징으로 하는 방법.
  14. 제 12항에 있어서,
    상기 주 데이터 유닛들의 소스와 상기 제 2 데이터 소스는, 서로 다른 미디어에 위치한 것을 특징으로 하는 방법.
  15. 제 12항에 있어서,
    상기 제 2 데이터 소스는, 가상 데이터 소스인 것을 특징으로 하는 방법.
  16. 제 15항에 있어서,
    상기 하나 이상의 제 2 데이터 유닛들은, 콜백(callback)에 의하여 특정되는 것을 특징으로 하는 방법.
  17. 제 1항에 있어서,
    상기 시스템은, 고속 기억장치를 더 포함하고,
    상기 d) 과정은,
    상기 미디어 장치에서 상기 고속 기억장치로 하나 이상의 데이터 유닛들을 프리 페치하는(pre-fetching) 과정과,
    상기 데이터 유닛들을 상기 고속 기억장치로부터 잇따라 전송하는 과정을 포함하는 것을 특징으로 하는 방법.
  18. 제 17항에 있어서,
    상기 고속 기억장치는, 하드 디스크 드라이브인 것을 특징으로 하는 방법.
  19. 제 18항에 있어서,
    상기 미디어 장치는, 대용량 광디스크 드라이브(high-capacity optical disc drive)인 것을 특징으로 하는 방법.
  20. 제 17항에 있어서,
    상기 하나 이상의 데이터 유닛들을 프리 페치하는 과정은, I/O가 대기 상태(idle)인 시간 동안 상기 하나 이상의 데이터 유닛들을 프리 페치하는 과정을 포함하는 것을 특징으로 하는 방법.
  21. 제 20항에 있어서,
    상기 하나 이상의 데이터 유닛들을 프리 페치하는 과정은,
    상기 미디어 장치로부터의 하나 이상의 데이터 유닛들의 제 1 그룹을 프리 페치하는 과정과,
    상기 미디어 장치의 대기 상태 여부를 확인하는 과정과,
    I/O 가 대기 상태에 있으면, 상기 미디어 장치로부터의 하나 이상의 데이터 유닛들의 제 2 그룹을 프리 페치하고, I/O가 대기 상태에 있지 않으면, 상기 제 2 그룹의 프리 페치 과정을 지연하는 과정을 포함하는 것을 특징으로 하는 방법.
  22. 제 2항에 있어서,
    상기 b) 과정은, 상기 시스템과 연관된, 상기 미디어 장치 보다 더 느린 미디어 장치의 작업을 에뮬레이션 하기 위해 상기 하나 이상의 파라미터들을 조정하는 과정을 포함하는 것을 특징으로 하는 방법.
  23. 프로세서부와,
    상기 프로세서부에 연결된 메모리와,
    상기 프로세서부에 연결된 미디어 장치와, 및
    상기 메모리에 내장된 프로세서 실행가능하며, 실행 시, 상기 미디어 장치와 왕복적으로 입출력(I/O)하는 과정을 처리하는 방법을 구현하도록 설정된 인스트럭션들의 세트를 포함하는 시스템으로,
    상기 방법은,
    a) 상기 미디어 장치와 왕복적으로 데이터를 전달하기 위해 상기 프로세서에서 실행되는 어플리케이션(application)으로부터의 인커밍(incoming) I/O 요청을 수신하는 과정과,
    b) 상기 인커밍 I/O 요청을 완료하기 위한 예상 시간(TP)을 연산하는 과정과,
    c) 상기 메모리에 내장된 스케줄에 상기 인커밍 I/O 요청을 삽입하는 과정과,
    d) 상기 스케줄에 따라 상기 인커밍 I/O 요청 및 상기 인커밍 I/O 요청의 다음 차례(subsequent) I/O 요청을 수행(service)하는 과정을 포함하고,
    상기 다음 차례 I/O 요청은 상기 인커밍 I/O 요청이 수행되기 이전에 수신되며, 상기 인커밍 I/O 요청이 완전히 다 수행된 이후에 수행되며,
    상기 스케줄 내에 있는 상기 인커밍 I/O 요청의 위치는,
    적어도 부분적으로 상기 예상 시간(TP)에 의존하고,
    상기 프로세서 실행가능한 인스트럭션들의 일군은,
    디아카이버(de-archiver) 계층, RAM 캐시(RAM cache) 계층, 스케줄러 캐시 계층, 오버레이(overlay) 계층, 카탈로그 캐시 계층, 데이터 변환 계층 및 시뮬레이션 된 데이터 계층 중 어느 하나를 포함하는 하나 이상의 미디어 필터 계층들을 더 포함하는 것을 특징으로 하는 시스템.
  24. 메인 프로세서, 연계된 로컬 메모리를 구비한 보조 프로세서, 메인 메모리 및 미디어 장치를 구비한 시스템에 있어서, 상기 미디어 장치와 왕복적으로 입출력(input or output; I/O)하는 과정을 처리하기 위한 방법으로,
    a) 상기 미디어 장치와 왕복적으로 데이터를 전달하기 위해 상기 메인 프로세서에서 실행되는 어플리케이션(application)으로부터의 인커밍(incoming) I/O 요청을 수신하는 과정과,
    b) 상기 메인 메모리에 내장된 스케줄에 상기 인커밍 I/O 요청을 삽입하는 과정과,
    c) 상기 스케줄 및 하나 이상의 필터에 따라 상기 인커밍 I/O 요청을 수행(service)하는 과정을 포함하고,
    상기 인커밍 I/O 요청이 수행되기 이전에 수신된 상기 스케줄 내의 상기 인커밍 I/O 요청의 다음 차례(subsequent) I/O 요청은, 상기 인커밍 I/O 요청이 완전히 다 수행된 이후에 수행되며,
    상기 하나 이상의 필터 중 적어도 하나는 상기 보조 프로세서에 의해 구현되는 것을 특징으로 하는 방법.
  25. 프로세서부, 메모리 및 미디어 장치를 구비한 시스템에 있어서, 상기 미디어 장치와 왕복적으로 입출력(input or output; I/O)하는 과정을 처리하기 위한 방법으로,
    a) 상기 미디어 장치와 왕복적으로 데이터를 전달하기 위해 상기 프로세서부에서 실행되는 어플리케이션(application)으로부터의 인커밍(incoming) I/O 요청을 수신하는 과정과,
    b) 상기 인커밍 I/O 요청을 완료하기 위한 예상 시간(TP)을 연산하는 과정과,
    c) 상기 메모리에 내장된 스케줄에 상기 인커밍 I/O 요청을 삽입하는 과정과,
    d) 상기 스케줄에 따라 상기 인커밍 I/O 요청 및 상기 인커밍 I/O 요청의 다음 차례(subsequent) I/O 요청을 구현하는 과정을 포함하고,
    상기 다음 차례 I/O 요청은, 상기 인커밍 I/O 요청이 구현되기 이전에 수신되며, 상기 인커밍 I/O 요청이 완전히 구현된 이후에 구현되며,
    상기 스케줄 내에 있는 상기 인커밍 I/O 요청의 위치는,
    적어도 부분적으로 상기 예상 시간(TP)에 의존하고,
    상기 d) 과정은,
    압축되고 네스팅 된 아카이브에서의 특정 데이터를 추출하는 과정을 포함하는 것을 특징으로 하는 방법.
  26. 프로세서부, 메모리 및 미디어 장치를 구비한 시스템에 있어서, 상기 미디어 장치와 왕복적으로 입출력(input or output; I/O)하는 과정을 처리하기 위한 방법으로,
    a) 상기 미디어 장치와 왕복적으로 데이터를 전달하기 위해 상기 프로세서부에서 실행되는 어플리케이션(application)으로부터의 인커밍(incoming) I/O 요청을 수신하는 과정과,
    b) 상기 인커밍 I/O 요청을 완료하기 위한 예상 시간(TP)을 연산하는 과정과,
    c) 상기 메모리에 내장된 스케줄에 상기 인커밍 I/O 요청을 삽입하는 과정과,
    d) 상기 스케줄에 따라 상기 인커밍 I/O 요청 및 상기 인커밍 I/O 요청의 다음 차례(subsequent) I/O 요청을 구현하는 과정을 포함하고,
    상기 다음 차례 I/O 요청은, 상기 인커밍 I/O 요청이 구현되기 이전에 수신되며, 상기 인커밍 I/O 요청이 완전히 다 구현된 이후에 구현되며,
    상기 스케줄 내에 있는 상기 인커밍 I/O 요청의 위치는,
    적어도 부분적으로 상기 예상 시간(TP)에 의존하고,
    상기 d) 과정은,
    데이터 오버레이 과정을 구현하는 과정을 포함하고,
    상기 미디어 장치와 상기 메모리 사이에서 전송되는 하나 이상의 주 데이터 단위들은 제 2 데이터 소스로부터의 하나 이상의 제 2 데이터 유닛들로 대체되는 것을 특징으로 하는 방법.
  27. 제 26항에 있어서,
    상기 주 데이터 유닛들의 소스와 상기 제 2 데이터 소스는 동일한 미디어에 위치한 것을 특징으로 하는 방법.
  28. 제 26항에 있어서,
    상기 주 데이터 유닛들의 소스와 상기 제 2 데이터 소스는 서로 다른 미디어에 위치한 것을 특징으로 하는 방법.
  29. 제 26항에 있어서,
    상기 제 2 데이터 소스는, 가상 데이터 소스인 것을 특징으로 하는 방법.
  30. 제 29항에 있어서,
    상기 하나 이상의 제 2 데이터 유닛들은, 콜백(callback)에 의해 특정되는 것을 특징으로 하는 방법.
  31. 프로세서부, 메모리, 고속 기억장치 및 미디어 장치를 구비한 시스템에 있어서, 상기 미디어 장치와 왕복적으로 입출력(input or output; I/O)하는 과정을 처리하기 위한 방법으로,
    a) 상기 미디어 장치와 왕복적으로 데이터를 전달하기 위해 상기 프로세서부에서 실행되는 어플리케이션(application)으로부터의 인커밍(incoming) I/O 요청을 수신하는 과정과,
    b) 상기 인커밍 I/O 요청을 완료하기 위한 예상 시간(TP)을 연산하는 과정과,
    c) 상기 메모리에 내장된 스케줄에 상기 인커밍 I/O 요청을 삽입하는 과정과,
    d) 상기 스케줄에 따라 상기 인커밍 I/O 요청 및 상기 인커밍 I/O 요청의 다음 차례(subsequent) I/O 요청을 구현하는 과정을 포함하고,
    상기 다음 차례 I/O 요청은, 상기 인커밍 I/O 요청이 구현되기 이전에 수신되며, 상기 인커밍 I/O 요청이 완전히 다 구현된 이후에 구현되며,
    상기 스케줄 내에 있는 상기 인커밍 I/O 요청의 위치는,
    적어도 부분적으로 상기 예상 시간(TP)에 의존하고,
    상기 d) 과정은,
    상기 미디어 장치에서 상기 고속 기억장치로 하나 이상의 데이터 유닛들을 프리 페치하는(pre-fetching) 과정과,
    상기 데이터 유닛들을 상기 고속 기억장치로부터 잇따라 전송하는 과정을 포함하는 것을 특징으로 하는 방법.
  32. 제 31항에 있어서,
    상기 고속 기억장치는, 하드 디스크 드라이브인 것을 특징으로 하는 방법.
  33. 제 32항에 있어서,
    상기 미디어 장치는, 대용량 광디스크 드라이브(high-capacity optical disc drive)인 것을 특징으로 하는 방법.
  34. 제 33항에 있어서,
    상기 하나 이상의 데이터 유닛들을 프리 페치하는 과정은, I/O가 대기 상태(idle)인 시간 동안 상기 하나 이상의 데이터 유닛들을 프리 페치하는 과정을 포함하는 것을 특징으로 하는 방법.
  35. 제 33항에 있어서,
    상기 하나 이상의 데이터 유닛들을 프리 페치하는 과정은,
    상기 미디어 장치로부터의 하나 이상의 데이터 유닛들의 제 1 그룹을 프리 페치하는 과정과,
    상기 미디어 장치의 대기 상태 여부를 확인하는 과정과,
    I/O가 대기 상태에 있으면, 상기 미디어 장치로부터의 하나 이상의 데이터 유닛들의 제 2 그룹을 프리 페치하고, I/O가 대기 상태에 있지 않으면, 상기 제 2 그룹의 프리 페치 과정을 지연하는 과정을 포함하는 것을 특징으로 하는 방법.
  36. 프로세서부, 메모리, 고속 기억장치 및 미디어 장치를 구비한 시스템에 있어서, 상기 미디어 장치와 왕복적으로 입출력(input or output; I/O)하는 과정을 처리하기 위한 방법으로,
    a) 상기 미디어 장치와 왕복적으로 데이터를 전달하기 위해 상기 프로세서부에서 실행되는 어플리케이션(application)으로부터의 인커밍(incoming) I/O 요청을 수신하는 과정과,
    b) 상기 인커밍 I/O 요청을 완료하기 위한 예상 시간(TP)을 연산하는 과정과,
    c) 상기 메모리에 내장된 스케줄에 상기 인커밍 I/O 요청을 삽입하는 과정과,
    d) 상기 스케줄에 따라 상기 인커밍 I/O 요청을 구현하는 과정을 포함하고,
    상기 인커밍 I/O 요청이 구현되기 이전에 수신된 상기 스케줄 내의 상기 인커밍 I/O 요청의 다음 차례(subsequent) I/O 요청은, 상기 인커밍 I/O 요청이 완전히 다 구현된 이후에 구현되며,
    상기 스케줄 내에 있는 상기 인커밍 I/O 요청의 위치는,
    적어도 부분적으로 상기 예상 시간(TP)에 의존하고,
    상기 b) 과정은,
    상기 시스템과 연관된, 상기 미디어 장치 보다 더 느린 미디어 장치의 작업을 에뮬레이션 하기 위해 하나 이상의 파라미터들을 조정하는 과정을 포함하는 것을 특징으로 하는 방법.
  37. 제1항에 있어서, 상기 c) 과정에서, 상기 인커밍 I/O 요청은, 상기 인커밍 I/O 요청을 포함하여 상기 스케줄 내에 있는 모든 I/O 요청이 각각의 기한을 놓치지 않도록 삽입되는 것을 특징으로 하는 방법.
  38. 제23항에 있어서, 상기 c) 과정에서, 상기 인커밍 I/O 요청은, 상기 인커밍 I/O 요청을 포함하여 상기 스케줄 내에 있는 모든 I/O 요청이 각각의 기한을 놓치지 않도록 삽입되는 것을 특징으로 하는 시스템.
  39. 제24항에 있어서, 상기 b) 과정에서, 상기 인커밍 I/O 요청은, 상기 인커밍 I/O 요청을 포함하여 상기 스케줄 내에 있는 모든 I/O 요청이 각각의 기한을 놓치지 않도록 삽입되는 것을 특징으로 하는 방법.
  40. 제25항에 있어서, 상기 c) 과정에서, 상기 인커밍 I/O 요청은, 상기 인커밍 I/O 요청을 포함하여 상기 스케줄 내에 있는 모든 I/O 요청이 각각의 기한을 놓치지 않도록 삽입되는 것을 특징으로 하는 방법.
  41. 제26항에 있어서, 상기 c) 과정에서, 상기 인커밍 I/O 요청은, 상기 인커밍 I/O 요청을 포함하여 상기 스케줄 내에 있는 모든 I/O 요청이 각각의 기한을 놓치지 않도록 삽입되는 것을 특징으로 하는 방법.
  42. 제31항에 있어서, 상기 c) 과정에서, 상기 인커밍 I/O 요청은, 상기 인커밍 I/O 요청을 포함하여 상기 스케줄 내에 있는 모든 I/O 요청이 각각의 기한을 놓치지 않도록 삽입되는 것을 특징으로 하는 방법.
  43. 제36항에 있어서, 상기 c) 과정에서, 상기 인커밍 I/O 요청은, 상기 인커밍 I/O 요청을 포함하여 상기 스케줄 내에 있는 모든 I/O 요청이 각각의 기한을 놓치지 않도록 삽입되는 것을 특징으로 하는 방법.
KR1020107029818A 2008-05-30 2009-05-08 파일 입출력 스케줄러 KR101238163B1 (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US12/130,892 2008-05-30
US12/130,892 US8504736B2 (en) 2008-05-30 2008-05-30 File input/output scheduler
PCT/US2009/043387 WO2009148764A1 (en) 2008-05-30 2009-05-08 File input/output scheduler

Publications (2)

Publication Number Publication Date
KR20110019763A KR20110019763A (ko) 2011-02-28
KR101238163B1 true KR101238163B1 (ko) 2013-03-11

Family

ID=41381486

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020107029818A KR101238163B1 (ko) 2008-05-30 2009-05-08 파일 입출력 스케줄러

Country Status (6)

Country Link
US (1) US8504736B2 (ko)
EP (1) EP2301002A4 (ko)
JP (1) JP5385977B2 (ko)
KR (1) KR101238163B1 (ko)
CN (1) CN102047305B (ko)
WO (1) WO2009148764A1 (ko)

Families Citing this family (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8504736B2 (en) * 2008-05-30 2013-08-06 Sony Computer Entertainment America Inc. File input/output scheduler
US8752100B2 (en) * 2008-08-29 2014-06-10 At&T Intellectual Property Ii, Lp Systems and methods for distributing video on demand
US8078799B2 (en) * 2009-06-10 2011-12-13 Lsi Corporation Method and system of an adaptive input/output scheduler for storage arrays
US8310492B2 (en) * 2009-09-03 2012-11-13 Ati Technologies Ulc Hardware-based scheduling of GPU work
US9852143B2 (en) 2010-12-17 2017-12-26 Microsoft Technology Licensing, Llc Enabling random access within objects in zip archives
US20130067237A1 (en) * 2011-09-12 2013-03-14 Microsoft Corporation Providing random access to archives with block maps
US20130159382A1 (en) * 2011-12-15 2013-06-20 Microsoft Corporation Generically presenting virtualized data
US9858149B2 (en) * 2012-01-03 2018-01-02 Microsoft Technology Licensing, Llc Accessing overlay media over a network connection
WO2014002079A2 (en) * 2012-06-29 2014-01-03 Happy Cloud Inc. Managing the writing of a dataset to a data storage device
US8983237B2 (en) 2012-08-22 2015-03-17 Adobe Systems Incorporated Non-destructive collaborative editing
US9390155B2 (en) 2012-08-22 2016-07-12 Adobe Systems Incorporated Accessing content in a content-aware mesh
US9514157B2 (en) * 2012-08-22 2016-12-06 Adobe Systems Incorporated Multi-dimensional browsing of content
US20140068621A1 (en) * 2012-08-30 2014-03-06 Sriram Sitaraman Dynamic storage-aware job scheduling
US9519574B2 (en) * 2012-11-28 2016-12-13 Microsoft Technology Licensing, Llc Dynamic content access window loading and unloading
CN104346220B (zh) * 2013-07-31 2017-11-03 中国科学院计算技术研究所 一种任务调度方法与系统
US9372716B1 (en) * 2013-09-23 2016-06-21 Amazon Technologies, Inc. Download prioritization
CN105763481A (zh) * 2014-12-19 2016-07-13 北大方正集团有限公司 一种信息缓存方法及装置
KR102311229B1 (ko) 2015-03-04 2021-10-14 (주)솔레컨스 멀티미디어 데이터 저장 시스템 기반 파일 정보를 중복으로 저장하는 시스템 및 방법
CN105159774B (zh) * 2015-07-08 2018-06-12 清华大学 一种api请求保序处理方法及系统
JP6243884B2 (ja) * 2015-10-02 2017-12-06 株式会社ソニー・インタラクティブエンタテインメント 情報処理装置、プロセッサ、および情報処理方法
US10635596B2 (en) 2015-10-02 2020-04-28 Sony Interactive Entertainment Inc. Information processing device, access controller, information processing method, and computer program for accessing memory having access units of different sizes
US10042749B2 (en) 2015-11-10 2018-08-07 International Business Machines Corporation Prefetch insensitive transactional memory
JP6734760B2 (ja) * 2015-11-10 2020-08-05 インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ プリフェッチ・インセンシティブのトランザクション・メモリ
US10645162B2 (en) * 2015-11-18 2020-05-05 Red Hat, Inc. Filesystem I/O scheduler
CN105549910B (zh) * 2015-12-14 2018-09-07 浪潮(北京)电子信息产业有限公司 一种io调度方法及装置
US10614092B2 (en) 2017-01-24 2020-04-07 International Business Machines Corporation Optimizing data retrieval operation in big-data processing systems
US10496335B2 (en) 2017-06-30 2019-12-03 Intel Corporation Method and apparatus for performing multi-object transformations on a storage device
US10824598B2 (en) * 2018-08-07 2020-11-03 Dell Products L.P. Handling file commit and commit-delete operations in an overlay optimizer
KR102254501B1 (ko) * 2018-10-19 2021-05-21 한양대학교 산학협력단 부분 순서 보장 기반의 입출력 스케줄러 및 그 방법
US11593156B2 (en) * 2019-08-16 2023-02-28 Red Hat, Inc. Instruction offload to processor cores in attached memory
US20210397526A1 (en) * 2020-06-18 2021-12-23 General Electric Company Systems and methods of providing an abstraction layer between an application layer and hardware components of a computing device
CN114706820B (zh) * 2022-05-18 2022-09-06 北京卡普拉科技有限公司 异步i/o请求的调度方法、系统、电子设备及介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030188092A1 (en) 2002-03-28 2003-10-02 Seagate Technology Llc Execution time dependent command schedule optimization for a disc drive
US6671772B1 (en) * 2000-09-20 2003-12-30 Robert E. Cousins Hierarchical file system structure for enhancing disk transfer efficiency

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5220653A (en) * 1990-10-26 1993-06-15 International Business Machines Corporation Scheduling input/output operations in multitasking systems
JPH08212090A (ja) * 1995-02-03 1996-08-20 Fujitsu Ltd サーバシステム
US6434569B1 (en) * 1996-06-06 2002-08-13 Kabushiki Kaisha Toshiba Integrated medical information system formed of text-based and image-based databases, and display thereof
US6157963A (en) * 1998-03-24 2000-12-05 Lsi Logic Corp. System controller with plurality of memory queues for prioritized scheduling of I/O requests from priority assigned clients
EP0978787A1 (en) * 1998-08-04 2000-02-09 Texas Instruments France Improvements in or relating to transferring data between asynchronous device
JP3975684B2 (ja) 2000-03-29 2007-09-12 富士通株式会社 ディスク入出力スケジュール装置および方法
US6587806B2 (en) * 2000-12-29 2003-07-01 Pitney Bowes Inc. Method and system for determining time to sort mailpieces
US6978355B2 (en) * 2001-11-13 2005-12-20 Seagate Technology Llc Cache memory transfer during a requested data retrieval operation
US6965965B2 (en) * 2002-06-06 2005-11-15 International Business Machines Corporation Dynamic response shaping for command aging
US7206866B2 (en) * 2003-08-20 2007-04-17 Microsoft Corporation Continuous media priority aware storage scheduler
US7590522B2 (en) * 2004-06-14 2009-09-15 Hewlett-Packard Development Company, L.P. Virtual mass storage device for server management information
US7260703B1 (en) 2004-08-20 2007-08-21 Sun Microsystems, Inc. Method and apparatus for I/O scheduling
JP4456490B2 (ja) 2005-01-14 2010-04-28 富士通株式会社 Ｄｍａ装置
JP5133540B2 (ja) 2006-09-05 2013-01-30 株式会社ソニー・コンピュータエンタテインメント 情報処理装置、データ転送方法及びプログラム
US7991948B2 (en) * 2008-01-30 2011-08-02 International Business Machines Corporation Optimizing execution of I/O requests for a disk drive in a computing system
US8504736B2 (en) * 2008-05-30 2013-08-06 Sony Computer Entertainment America Inc. File input/output scheduler

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6671772B1 (en) * 2000-09-20 2003-12-30 Robert E. Cousins Hierarchical file system structure for enhancing disk transfer efficiency
US20030188092A1 (en) 2002-03-28 2003-10-02 Seagate Technology Llc Execution time dependent command schedule optimization for a disc drive

Also Published As

Publication number Publication date
JP5385977B2 (ja) 2014-01-08
CN102047305A (zh) 2011-05-04
US20090300642A1 (en) 2009-12-03
EP2301002A4 (en) 2016-05-25
WO2009148764A1 (en) 2009-12-10
EP2301002A1 (en) 2011-03-30
CN102047305B (zh) 2014-06-25
KR20110019763A (ko) 2011-02-28
JP2011525010A (ja) 2011-09-08
US8504736B2 (en) 2013-08-06

Similar Documents

Publication Publication Date Title
KR101238163B1 (ko) 파일 입출력 스케줄러
KR101188472B1 (ko) 데이터 즉시 청킹을 사용하여 파일 입출력을 스케줄 하는 방법
US9043504B2 (en) Interfaces for digital media processing
KR101378390B1 (ko) 공유 스택의 부분들을 할당하기 위한 시스템 및 방법
US8244935B2 (en) Write aggregation using optional I/O requests
KR101979621B1 (ko) 다운로드 가능한 컨텐츠의 전송을 최적화하는 시스템 및 장치
US20110302365A1 (en) Storage system using a rapid storage device as a cache
JP2013501296A (ja) スレッド移送におけるキャッシュのプレフィル
US20080147213A1 (en) Lock-Free Shared Audio Buffer
JP4634477B2 (ja) メディア・ファイルの中断のない再生方法
KR20080044872A (ko) 컴퓨터 상에서 정보 또는 데이터를 처리하기 위한 시스템및 방법
JP2007501473A (ja) メインメモリとストレージ装置との間のデータ転送を行うための方法及び装置
EP4020197B1 (en) Methods and apparatus for loading of a container image
US8200899B2 (en) Method and system for providing digital rights management files using caching
JP2005057688A (ja) 画像処理方法、画像処理プログラムおよび画像処理装置
EP1685568A2 (en) Method and apparatus for reproducing data from an optical storage device

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20160205

Year of fee payment: 4

FPAY Annual fee payment

Payment date: 20180208

Year of fee payment: 6

FPAY Annual fee payment

Payment date: 20200213

Year of fee payment: 8