<30322DC0CCBDC2C0E72C20C1D6BFB5B0FC2C20C0FCC1DFB3B25F DC6ED2E687770>

Transcription

1 SSD 버퍼 크기를 고려한 리눅스 입출력 스케줄러 성능분석 Performance Analysis of Linux I/O Scheduler By Considering SSD Buffer Size 이승재*, 주영관*, 전중남* * Seungjae Lee*, YoungKwan ju*, Joongnam Jeon* *충북대학교 컴퓨터과학과 * Department of Computer Science, Chungbuk National University, Cheongju, Chungbuk Korea Abstract Recently, Solid State Drives (SSDs) become an alternative storage to traditional magnetic hard disk drives (HDDs) for rapid performance in desktop, laptop, and enterprise fields, because the performance, reliability, durability and power efficiency of SSD are better than those of HDDs. Current I/O scheduler is optimized for rotational magnetic storages. Thus the I/O scheduler needs to be modified to utilize the I/O characteristics of SSD. This thesis analyzes the performance variation of Linux I/O scheduler according to the size of I/O requests, which is the scheduling priority, when the buffer size of SSD is fixed. The results of this analysis can be utilized to design the scheduling policy of I/O scheduler for SSD. An I/O scheduling simulator is designed for this study, and it is dispatching I/O requests by order of data size and priority to the block devices. The I/O scheduling simulator has LISF (Largest I/O Size First) and SISF (Smallest I/O Size First) queues for reordering I/O requests based on their I/O request size. These queues are used to change of dispatching priority based on the predetermined I/O size. When the dispatching priority is set to the buffer size of SSD, the simulator puts higher priority to the I/O requests whose size is close to the dispatching priority. The simulation has been performed by changing the dispatching priority 0 MB to 4 MB on an SSD of 512 KB buffer size, and applying six benchmark workloads. The simulation results suggest that changing dispatching priority according to the I/O request size of current workload would be better rather than fixing the dispatching priority to a certain size. Keywords: SSD, Operating System, I/O Scheduler 요 약 최근 SSD는 데스크탑, 랩탑 및 엔터프라이즈 영역에서 빠른 성능을 위해 기존 마그네틱 하드디스크의 대안으로 되고 있 다. SSD의 성능, 신뢰성, 내구성과 전력 효율이 하드디스크보다 좋기 때문이다. 현재 입출력 스케줄러의 설계는 회전하는 자 기 저장 장치에 최적화 되어있다. 따라서 입출력 스케줄러는 SSD의 입출력 특성을 이용하여 최적화 되어야 한다. 이 논문은 SSD의 버퍼 크기가 정해져 있을 때, 입출력 요청에 크기에 따라 우선순위를 변경하여 리눅스 입출력 스케줄러 의 성능 변화를 분석한다. 이 분석의 결과는 SSD를 위한 리눅스 입출력 스케줄러의 스케줄링 정책을 설계하는데 이용될 수 있다. 입출력 스케줄 시뮬레이터는 이 연구를 위해 설계되었고, 입출력 요청들을 데이터 크기로 우선순위를 결정하여 블록 디바 이스로 보낸다. 시뮬레이터는 입출력 요청의 크기를 바탕으로 입출력 요청을 재 정렬하는 LISF (Largest I/O Size First) 큐와 SISF (Smallest I/O Size First) 큐를 갖는다. 이 큐들은 입출력 요청의 크기를 바탕으로 입출력 요청의 디스패치 우선순위를 변경하는데 사용된다. 디스패치 우선순위를 SSD의 버퍼 크기로 설정하면, 시뮬레이터는 입출력 요청의 크기가 설정된 디스패치 우선순위에 가까운 입출력 요청에 높은 우선순위를 부여한다. 시뮬레이션은 실험에서 사용된 SSD의 버퍼 크기인 512KB 포함하여 0KB 4MB까지 디스패치 우선순위를 변경하고, 여 섯 가지의 워크로드를 적용하여 수행된다. 시뮬레이션 결과로 디스패치 우선순위와 각각 부하마다 다른 성능을 보이기 때문에, 디스패치 우선순위를 특정 크기로 고 정하는 것이 아니라 현재의 작업 부하에 따라 디스패치 우선순위를 동적으로 변경할 필요가 있다는 결론을 얻을 수 있었다. Keywords: SSD, 운영체제, 입출력 스케줄러 * 교신저자 : tuxmong@cbnu.ac.kr - 7 -

2 컴퓨터정보통신연구 제22권 제2호 (7-16) 1. 서 론 지금까지의 입출력 시스템은 전통적인 자기식 보조기 억장치인 하드디스크(HDD)의 디스크 암과 헤드의 탐색 시간, 회전지연 시간과 같은 데이터 입출력의 오버헤드를 줄이기 위해 입출력 스케줄러, 파일시스템, 버퍼 캐싱 그 리고 NCQ(Native Command Queuing)와 같은 디스 크 암과 헤드 움직임 최소화 등의 여러 계층에서 HDD의 성능을 최적화하기 위해 애써왔다. HDD는 디스크 암이 이동하여 데이터가 있는 위치로 이동을 하고 디스크가 회전하면서 데이터가 기록된 부분 이 디스크 암 끝에 있는 헤드로 올 때 까지 기다려야하는 기계적인 장치이다. 이와 같은 물리적인 특성의 이유로 발생하는 지연에 대한 성능 최적화는 한계가 있다. 그래 서 전기적인 신호로 데이터에 접근하여 물리적인 지연을 해결하면서 더욱 빠르고 안정적인 반도체 메모리를 이용 한 보조기억장치들이 등장 하였지만 비싼 가격으로 인하 여 대중화에 어려움이 있었다. 하지만 최근 반도체 메모리 중 NAND 플래시 메모리 의 가격이 저렴해지면서 NAND 플래시 메모리를 기반으 로 하는 저장장치인 SSD(Solid State Drive)가 데스크 탑, 랩탑, 그리고 엔터프라이즈 서버 등에서 널리 사용되 고 있다. 왜냐하면 SSD는 성능, 신뢰성, 전력소모량과 내구성이 기존 HDD 보다 우수하기 때문이다. SSD는 NAND 플래시 메모리들의 집합으로 구성되어 있다. 그래서 SSD는 HDD와 같이 기계적인 방식으로 데이터에 접근하지 않고 전기적 방식으로 데이터에 접근 하기 때문에 헤드의 탐색시간과 디스크의 회전 지연시간 과 같은 오버헤드가 없어 HDD보다 성능이 우수하다. 그러나 SSD와 같은 고성능의 보조기억장치가 등장에 도 불구하고 여전히 HDD에 최적화된 운영체제와 하드 웨어로 인하여 SSD가 제대로 성능을 발휘하지 못하고 있다. 그래서 SSD를 위한 파일시스템, 블록 디바이스 드라이버 SSD 내부 시스템 등의 여러 계층에서 최적화 가 필요하다. 그래서 이 논문은 SSD와 운영체제의 입출력 서브시스 템 사이에서 성능에 초점을 두었으며, 리눅스의 입출력 서브시스템 중에서 입출력 스케줄러의 성능 분석을 시행 하였다. 실험을 위해 운영체제의 입출력 시스템의 분석이 필요하였기 때문에, 운영체제의 내부가 공개 되어 있는 리눅스가 이 실험에 적합하다고 판단하여 이 논문에서는 리눅스를 기준으로 분석하였다 연구의 목적 최근 수십 년 동안 리눅스의 입출력 서브시스템은 HDD에 최적화에 애써왔다. 리눅스의 입출력 서브시스템 은 크게 데이터를 관리하는 파일 시스템과 요청을 관리하 는 일반 블록 계층 그리고 블록 장치를 관리하는 블록 디 바이스 드라이버 계층으로 되어 있다. 이들 중 파일시스 템은 SSD, 플래시 메모리등과 같은 고성능 스토리지를 고려한 파일시스템들이 존재 하지만, 아직까지도 일반 블 록 계층은 입출력 요청들을 병합하여 최대한의 데이터양 을 하나의 입출력 요청으로 만들고 HDD의 탐색 시간을 줄이기 위해 입출력 요청들의 순서를 재 정렬 등을 통해 HDD에 최적화 하고 있다. 이러한 작업을 일반 블록 계 층과 입출력 스케줄러 계층이 협력하여 수행한다. 입출력 스케줄러는 입출력 요청이 들어왔을 때 병합과 재 정렬을 통해 저장장치와 입출력시스템 사이에서 성능 을 최적화하기 위한 리눅스 입출력 서브시스템 중 하나이 다. 기존 리눅스가 제공하는 입출력 스케줄러는 입출력 요청을 정렬을 시도할 때 HDD의 디스크 암과 헤드의 기 계적인 움직임을 최소화하여 이동으로 인한 탐색 지연시 간을 줄이기 위해 섹터 번호 순서로 정렬을 한다. 이 방 법은 기존 디스크로 운영되는 HDD에 최적화된 기법이 며 SSD는 디스크와 섹터가 존재하지 않고 전기적으로 데이터에 접근하기 때문에 섹터 번호 순서로 재 정렬 할 필요가 없다. 예를 들면 리눅스가 제공하는 입출력 스케줄러 중에서 NOOP(No Operator) 입출력 스케줄러가 있다. 이 입 출력 스케줄러는 입출력 요청을 섹터 번호 순서로 재 정 렬 없이 들어온 순서대로 보조 기억 장치로 보낸다. 이 입출력 스케줄러는 리눅스의 다른 입출력 스케줄러에 비 해 SSD와 같은 회전과 탐색시간이 없는 저장장치에 유 리 하지만, NOOP는 오직 들어온 순서대로 입출력 요청 을 보조 기억 장치에 전달만 할뿐이고 SSD의 특성들을 고려하지 않고 설계된 입출력 스케줄러이다. 그래서 SSD와 같은 고성능 저장장치는 새로운 정렬방 법과 기존 입출력 스케줄러처럼 하드웨어의 특성을 고려 하여 입출력 스케줄러를 재설계할 필요성이 있다고 보고 SSD의 특성들을 입출력 스케줄러에 적용하였을 때 어떠 한 영향이 있는지 분석할 필요가 있다 생각하여 이 연구 를 수행하였다 연구내용 이 논문에서는 SSD의 특성 중 버퍼 크기를 고려해서 입출력 스케줄러를 재설계하였을 때 성능에 어떠한 변화 가 있는지 시뮬레이터를 통해 리눅스 입출력 스케줄러의 성능을 분석하였다. 여기서 성능은 대역폭과 지연시간을 의미한다. 첫째, 이 연구의 실험을 위해 입출력 요청의 크기 순서 로 정렬을 하고, 특정 크기를 기준으로 우선순위를 부여 하는 입출력 스케줄러 계층에서 동작하는 시뮬레이터를 구현하였다. 둘째, 입출력 요청 중 SSD의 버퍼 크기와 같거나 가 까운 요청에게 우선순위를 높게 한다. 그리고 입출력 요 청을 높은 우선순위부터 차례로 SSD로 보내어 대역폭과 지연시간을 분석하였다. 셋째, 디스패치 우선순위를 SSD의 버퍼 크기 외 0KB 4MB 로 변경하여 이들의 성능 차이를 비교하여 입출 력 스케줄링시 입출력 요청의 크기로 우선순위를 부여하 - 8 -

3 SSD 버퍼 크기를 고려한 리눅스 입출력 스케줄러 성능분석 였을 때의 성능을 분석하였다. 넷째, 다양한 워크로드를 실험에 적용하여 데이터 크 기 순서로 정렬하고 우선순위를 부여했을 때 각각의 워크 로드와의 관계를 관찰하였다. 이 연구는 리눅스 커널 에서 실험 되었고 기존 리눅스의 입출력 스케줄러 기준으로 비교하였다. 2. 관련연구 2.1. SSD개요 SSD는 반도체를 이용하여 정보를 저장하는 반도체 드 라이브 이다. SSD는 그림 1과 같이 NAND플래시 메모 리 패키지, SSD 컨트롤러, DRAM, 그리고 호스트 인터 페이스로 구성된다[1 4,6,8 14,17]. SSD 컨트롤러는 플래시 프로세서, 메모리 컨트롤러, DRAM 컨트롤러 그리고 FTL 등을 포함하며 SSD를 운 영하는데 중요한 역할을 한다. SSD는 하나 이상의 NAND 플래시 메모리 패키지들로 구성되어 있다. 이 NAND 플래시 메모리 패키지들을 멀티채널 버스를 통해 병렬로 플래시 컨트롤러에 연결한다. 이러한 SSD의 내 부 병렬성을 이용하여 데이터 스트리핑과 인터리빙 기술 을 사용하여 SSD의 성능을 향상시켰다. 이지들을 하나로 모아 새로운 블록에 연속적으로 쓰고 기 존의 블록들을 지우고 쓰기 가능한 빈 블록 상태로 바꿔 무효한 페이지들을 재사용할 수 있게 하며 이 기능은 FTL이 관리한다.[8 11] SSD의 FTL(Flash Translation Layer)은 호스트의 읽기/쓰기 명령을 NAND 플래시 메모리의 읽기/쓰기/지 우기 명령으로 변환해주는 역할을 한다. FTL 알고리즘은 여러 개의 플래시 메모리로 구성된 SSD를 운영하는데 있 어 중요한 역할을 한다. FTL은 호스트에게 하드디스크처 럼 인식할 수 있도록 인터페이스를 변환하고 논리 블록 주 소를 호스트에서 플래시메모리의 물리 메모리로 맵핑 해 주는 역할과 가비지 컬렉션, 웨어 레벨링(Wear leveling)등이 주 목적인 SSD의 메인 소프트웨어이다. FTL은 SSD성능의 많은 영향을 끼치며 여러 알고리즘들 이 활발히 연구되고 있다[8,9]. SSD의 DRAM 컨트롤러는 호스트에서 들어오는 입출 력 요청들을 DRAM의 버퍼에 넣고 요청들을 관리한다. 고성능 스토리지인 SSD가 버퍼가 필요한 이유는 쓰기/ 지우기 속도가 느리기 때문에 외부장치와 SSD 간의 처 리 속도 차이를 줄여 주기 위해 쓰인다 리눅스 입출력 시스템 그림 2는 일반 블록 계층과 입출력 스케줄러 계층을 기술하고 있다. 일반 블록 계층은 요청된 데이터 전송을 위해 입출력 연산을 한다. 블록 입출력들과 입출력 요청들을 뒤 병합 (Back Merge)을 시도하고 새로운 입출력 요청을 만든 다. 그리고 앞 병합은 입출력 스케줄러에게 인터페이스를 제공하여 입출력 스케줄러의 정책에 따른다. 입출력 스케줄러는 일반 블록 계층에서 생성된 입출력 요청을 정렬하고 블록 입출력의 앞 병합(Front Merge) 을 시도하며, 정렬된 요청들을 스케줄링하여 블록 장치 드라이버로 보낸다. 그림 1. SSD 구조 SSD는 플래시 메모리 인터페이스와 호스트의 인터페 이스 사이에서 SATA, PATA, PCI-E, USB등의 프로 토콜로 연결을 제공해야 하는데 이는 호스트 인터페이스 컨트롤러가 관리한다. SSD는 호스트와는 읽기, 쓰기 연 산을 하지만 SSD 내부에서는 플래시 메모리의 읽기, 지 우기, 쓰기 정책에 따른다. 플래시 메모리는 호스트의 읽 기와 쓰기 연산은 플래시 메모리에 페이지 단위, 지우기 연산은 블록단위로 한다. 그러나 플래시 메모리는 덮어쓰 기가 금지되어 있다. 왜냐하면 플래시 메모리의 쓰기는 이미 지워져 있는 페이지에만 쓰기가 가능하기 때문이다. 그래서 데이터의 변경이 필요할 때 빈 페이지에 변경된 데이터를 저장하고 기존 페이지는 무효상태로 바꾼다. 이 무효한 페이지들이 누적이 되면 플래시 메모리의 내부 단 편화가 발생하게 되어 사용효율이 감소하게 된다. 이를 해결하기 위해 가비지 컬렉션이 유효한 데이터가 있는 페 그림 2. 리눅스 입출력 계층 구조 - 9 -

4 컴퓨터정보통신연구 제22권 제2호 (7-16) 2.3. 리눅스 입출력 시스템의 입출력 요청 처리 고 마지막으로 시스템 콜의 반환을 통해 출력의 경우 성 공적으로 끝냈는지 아니면 에러가 발생했는지를 전달하고 입력의 경우 입력 데이터를 반환한다[15,21] 리눅스 입출력 스케줄러 그림 3. 입출력 요청 처리 순서 그림 3과 같이 리눅스 입출력 서브시스템은 사용자 영 역에서 시스템 콜을 통해 입출력 연산이 발생하면, Direct I/O의 경우 가상 파일 시스템을 거쳐 블록 계층 으로 요청을 하게 된다. 만약 Direct I/O 아닌 경우 가 상 파일 시스템과 블록 계층 사이의 페이지 캐시에서 해 당 입출력의 페이지를 찾는다. 여기서 페이지 캐시는 가 상 파일 시스템이 디스크의 접근을 최소화하기 위해 페이 지 캐시를 이용하여 한번 접근한 보조 기억 장치의 내용 을 저장해 두어 또 다시 접근을 하게 될 경우 보조 기억 장치까지 접근하지 않고 바로 페이지 캐시에서 접근 가능 하도록 하는 역할을 한다. 만약 해당 입출력의 페이지를 찾지 못하면 블록 계층으로 Block I/O를 만들어 보낸다. 블록 계층에서는 이렇게 받은 Block I/O들의 병합을 시 도하고 블록 디바이스 드라이버의 콜백 함수를 통해 입출 력 요청(I/O Request)을 만든다. 이렇게 만들어진 입출 력 요청을 입출력 스케줄러에게 보내어 입출력 스케줄러 의 정책에 따라 입출력 요청들을 재 정렬하고 다시 한 번 병합을 시도한 후 드라이버로 보내기위해 디스패치 큐에 넣고 한번에 SCSI 서브시스템으로 보내진다. 그리고 나 서 SCSI 서브시스템은 DMA를 셋팅하고 블록 디바이스 드라이버의 콜백 함수를 호출하여 DMA를 통해 블록 디 바이스로 요청을 보낸다. 블록 디바이스가 입출력 처리가 끝나면 커널에게 인터럽트를 보낸다. 인터럽트를 받은 커 널은 인터럽트 핸들러를 통해 SCSI 시스템이 할당해준 자원을 해제하고 SoftIRQ로 넘겨 해당 핸들러에서 나머 지 입출력 요청을 완료하는데 필요한 작업을 한다. 그리 리눅스의 입출력 시스템은 가상 파일 시스템, 파일시 스템, 일반 블록 계층, 입출력 스케줄러, 블록 장치 드라 이버 등의 계층으로 구성된다. 블록 입출력이 발생하면 파일시스템을 거쳐 일반 블록 계층으로 보낸다. 그리고 블록입출력에 대해 병합을 시도하고 입출력 요청을 만든 후 입출력 스케줄러에게 보낸다. 입출력 스케줄러는 요청 들의 병합을 시도 할 수 있으며, 디스크 탐색시간을 최소 화하기 위해 요청들을 섹터 순으로 정렬한 다음 순서대로 디스크로 보내준다. 리눅스 는 완전 공평 큐잉(CFQ) 입출력 스케줄 러, 데드라인 입출력 스케줄러, 그리고 NOOP(No Operator) 입출력 스케줄러를 기본으로 제공한다. CFQ 입출력 스케줄러는 모든 프로세스들에게 입출력 대역폭을 공평하게 할당하는 것을 보장한다. 요청이 발생 한 각 프로세스마다 큐를 할당하며 이 큐들을 라운드로빈 으로 검색하고 비어있지 않은 큐를 선택 한 후 그 큐에서 일괄 처리 할 요청들을 디스패치 큐에 이동시킨다. 데드라인 입출력 스케줄러는 정렬된 큐와 FIFO큐를 두고 섹터 번호에 따라 정렬된 요청을 우선 처리하다 FIFO큐의 맨 앞의 요청이 마감시한이 지나면 FIFO큐 에 있는 요청부터 처리하여 기아현상(Starvation)을 방 지한다. NOOP 입출력 스케줄러는 정렬된 큐가 없으며 새로운 요청은 항상 디스패치 큐로 이동시킨다. 3. 입출력 스케줄러 시뮬레이터 설계 본 연구의 실험을 위해 구현한 SLQ(Smallest IO Size First and Largest IO Size First Queue) 입출 력 스케줄 시뮬레이터는 각 입출력 요청의 크기별로 정렬 하고 입출력 요청의 크기별로 우선순위를 부여한다. 그리 고 특정 입출력 요청의 크기를 디스패치 우선순위가 높게 설정할 수 있어 여러 조건으로 입출력 스케줄 시뮬레이션 을 한다. 그림 4는 SLQ 입출력 스케줄 시뮬레이터 구조 를 기술한 것이다. 그림 4. SLQ 입출력 스케줄 시뮬레이터 구조

5 SSD 버퍼 크기를 고려한 리눅스 입출력 스케줄러 성능분석 3.1. 입출력 스케줄링 정책 그림 5와 같이 1KB 512KB의 요청들은 LISF(Largest IO Size First) 큐에 요청의 크기 별로 내림차순으로 정렬 되고 큰 크기의 입출력 요청이 우선하여 디스패치 큐를 통하여 SSD로 보낸다. LISF 큐는 큰 크기 먼저 보내기 때문에 작은 크기의 요청들은 대기하는 동안 병합의 기회 를 갖는다. 512KB보다 큰 요청들은 SISF(Smallest IO Size First) 큐이다. 이 큐는 작은 크기의 입출력 요 청이 먼저 처리되고 오름차순으로 정렬하는 큐이다. 이 SISF 큐는 [4]에서 제안한 SITF 스케줄러와 같이 작은 크기의 요청을 먼저 함으로 응답시간이 줄일 수 있는 장 점이 있다. LISF 큐와 SISF 큐를 이용함으로써 그림 5 와 같이 우선순위 기준점이 생기고 이를 이용해서 이 실 험의 시뮬레이션을 할 수가 있다. 그림 6은 SLQ 입출력 스케줄 시뮬레이터 스케줄링 절차이다. 그림 5. 입출력 요청 크기별 디스패치 순서 능하다 읽기/쓰기 정책 SSD는 NAND 플래시 메모리의 쓰기 정책으로 인해 쓰기 성능은 읽기 성능보다 느리게 동작한다. 그리고 쓰기 요청은 속도보다 신뢰성이 보장 된다면 약간의 지연이 발생 하여도 되지만 읽기 요청은 프로세스에게 빠르게 응답을 해 야 입출력으로 인한 호스트의 전체적인 성능저하 영향을 미 치지 않게 된다. 그래서 SLQ 입출력 스케줄 시뮬레이터는 기존 리눅스 스케줄러의 데드라인 입출력 스케줄러를 기준으 로 읽기쓰기 정책을 2대1 비율로 디스패치 큐로 보낸다. 그 리고 이 정책은 사용자 영역에서 변경 가능하다 기아현상 방지 각각의 큐에 입출력 요청들이 정렬되면서 최악의 경우 입 출력 스케줄링 정책으로 인해 처음에 들어온 입출력 요청이 다른 입출력 요청들의 우선순위에 밀려 모든 요청이 끝날 때 까지 디스크로 보내지 못할 수 있다. 이러한 기아현상 (Starvation)을 해결하기위해 SLQ 입출력 스케줄 시뮬레 이터는 각 요청마다 만료시간을 부여하며 FIFO 큐에서 기 아현상을 방지하기위해 입출력 요청들을 관리한다. 그림 4.3과 같이 FIFO 큐는 입출력 요청이 들어온 순서대로 정 렬하고 큐 머리에 있는 입출력 요청의 만료시간이 지나면 다 른 큐들보다 우선적으로 처리한다. 만료시간은 데드라인 입 출력 스케줄러를 기준으로 기본 값을 읽기 500msec, 쓰기 5sec이다. 이 정책 역시 사용자 영역에서 변경 가능하다. 4. 입출력 스케줄러 성능 분석 표 1. 실험 환경 종류 CPU RAM SSD 세부사항 Intel Core i GHz 4GB DDR3 1600MHz Samsung 128GB SSD 840 PRO (MLC) OS Linux Kernel 그림 6. SLQ 입출력 스케줄 시뮬레이터 스케줄링 절차 3.2. 요청 크기 제한 SSD는 NAND플래시 메모리를 병렬로 구현하여 인터 리빙을 통해 SSD성능을 높였다. 이러한 SSD의 병렬성 을 고려하여 LBA-bundle을 제한한 IRBW 입출력 스케 줄러[2]와 유사한 방법으로 LBA-bundle 크기를 추출하 였다. 이렇게 해서 얻은 LBA-bundle 크기를 하나의 요 청이 병합할 수 있는 최대 크기로 기본 값으로 한다 [1,2,4]. 이 요청 크기 제한은 사용자 영역에서 변경 가 File System Target Benchmark tools Ext4 SLQ, CFQ, Deadline, NOOP Fio, Postmark, BlogBench, Dbench, Compilebench SSD의 버퍼 크기가 입출력 스케줄러에 미치는 영향을 실험하고 실험에서 측정된 값의 분석과 입출력 스케줄링 시 디스패치 우선순위를 SSD의 버퍼 크기 외 0KB 4MB 로 변경하여 이들의 성능 차이를 비교하여 입출력 스케줄링시 데이터의 크기로 디스패치 우선순위를 부여하 였을 때 성능에 어떠한 영향을 미치는지 분석하였다

6 컴퓨터정보통신연구 제22권 제2호 (7-16) 표 2. 벤치마크 도구별 워크로드 Benchmark Tools FIO A B Profile I/O Size : 4KB 8MB File Size : 256KB 512MB 순차 읽기/쓰기, 임의 읽기/쓰기 IOmeter Intel File Server Access Pattern Postmark BlogBench Number of files : 500 Transactions : 25,000 File size : 4KB 16MB Read/Write I/O size : 4KB Read/Write 그림 9. Fio-A워크로드 지연시간 측정 평균 - SLQ : 4MB, Others : 512KB Dbench Client Count : 128 Compile Arguments : -D t -i 10 --makej Compilebench Initial Create / Compile / Read Compiled Tree 그림 10. Fio-A워크로드 지연시간 측정 평균 - SLQ : 4MB, Others : 4MB 그림 7. Fio-A워크로드 대역폭 측정 평균 - SLQ : 4MB, Others : 512KB 그림 8. Fio-A워크로드 대역폭 측정 평균 - SLQ : 4MB, Others : 4MB 그림 11. Fio-B : IOmeter - Intel File Server Access Pattern

7 SSD 버퍼 크기를 고려한 리눅스 입출력 스케줄러 성능분석 그림 12. Postmark 대역폭 측정 그림 16. Compilebench 측정 대역폭 그림 17. SSD의 읽기/쓰기 버퍼 크기 측정 그림 13. Blogbench Read 측정 점수 그림 14. Blogbench Write 측정 점수 그림 18. SSD의 Buffer크기로 인한 추가 지연 식 (1) 그림 15. Dbench 측정 대역폭 표 3의 Fio-A의 결과를 보면 최대 요청 크기가 성능 에 영향을 미치는 것을 확인할 수 있다. 대역폭 면에서는

8 컴퓨터정보통신연구 제22권 제2호 (7-16) 4.7% 5.0% 향상 되는 것을 확인할 수 있지만 지연시 간 면에서는 5.4% 5.9% 지연되는 것을 확인할 수 있 다. 대역폭의 성능은 향상되지만 지연시간의 성능이 하락 하였다. 그 이유는 최대 요청 크기를 기본 값 512KB에 서 LBA-bundle 크기인 4MB로 하였기 때문이다. 만약 4MB의 큰 크기의 입출력 요청이 발생하면 SSD에서 내 부 병렬성을 이용하여 인터리빙을 통해 동시에 여러 개의 블록에 쓰기 및 읽기 연산을 할 수 있기 때문이다. 지연시간의 성능이 하락하는 것은 SSD의 버퍼의 크기 때문이다. SSD의 버퍼가 채워지고 비우고 다시 채우는 데 걸리는 시간이 있기 때문이다. 이 실험에 사용된 SSD는 그림 17와 같이 512KB의 버퍼크기를 갖고 있 다. 만약 그림 18과 같이 하나의 입출력 요청의 크기가 512KB를 넘을 때 마다 매번 약 100us 150us의 추가 지연이 발생한다. 예를 들어 2.3MB 크기의 입출력 요청 이 발생하였다 가정하면 약 400us 600us의 추가 지연 이 발생한다. 위 결과를 바탕으로 응답시간의 성능을 향 상시키려면 최대한 SSD의 내부 버퍼보다 작은 크기의 요청을 많이 최대한 많이 처리하는 것이 효과가 있다는 것을 알 수 있다. 그래서 지연시간의 성능을 고려하였을 경우에는 최대 요청 크기를 SSD의 내부 버퍼 크기만큼 제한하여 스케줄링 하는 것이 바람직하다. 그러나 여러 가지 워크로드로 실험하면서 각 각의 워 크로드마다 다른 성능이 나왔고, 디스패치 우선순위를 변 경하면서 실험을 하였을 경우도 워크로드마다 다른 성능 을 보여주었다. 왜냐하면 Fio-A와 달리 다른 워크로드들 은 실세계의 부하를 묘사한 것이기 때문에 여러 가지 순 차 읽기/쓰기. 임의 읽기/쓰기가 혼합되어 서로 다른 크 기의 입출력 데이터를 여러 개의 쓰레드들이 작업을 하기 때문에 서로 다른 특성과 결과를 보여준다. 5. 결론 및 향후 연구 방향 이 연구에서는 데이터 크기별로 우선순위를 부여하는 시뮬레이터를 구현하고 실험에 적용하였다. 이 시뮬레이 터를 이용하여 SSD의 버퍼크기를 고려하여 입출력 요청 들을 스케줄링 하였을 때 SSD의 성능에 미치는 영향과, 여러 워크로드에 스케줄링 디스패치 우선순위를 변경해 가면서 성능을 측정하여 우선순위별 성능 차이를 살펴보 았다. 비교대상은 기존 리눅스의 입출력 스케줄러들로 하 였다. 순차 읽기/쓰기, 임의 읽기/쓰기 각각 부하를 주어 비 교하였을 때 특별히 성능에 크게 미치는 영향을 볼 수 없 었다. SSD의 버퍼 크기로 디스패치 우선순위를 설정하 였을 때도 마찬가지로 크게 영향을 미치지는 않았다. 그러나 파일 서버환경, 컴파일 환경 등과 같은 워크로 드를 바꿔서 실험하였을 때 각각의 다른 결과들을 보여주 었다. 워크로드 Fio-A는 입출력 요청 크기 제한을 LBA-Bundle 크기로 설정하였을 때 5.4% 6.5%의 대역폭이 증가하 였다. 워크로드 Fio-B는 지연시간 80% 90%의 감소율 을 보였다. 워크로드 Postmark는 -8% 5%의 대역폭 표 3. 종합 비교표 - 디스패치 우선순위 : SSD 버퍼 크기[512KB] (SLQ기준) 워크로드 CFQ Deadline NOOP Fio-A:대역폭 최대 요청 크기 - SLQ:4MB, Others:512KB 4.9% 4.7% 5.0% Fio-A:대역폭 최대 요청 크기 - SLQ:4MB, Others:4MB 0.2% -0.1% -0.1% Fio-B:IOmeter-Intel File Server Access Pattern 대역폭-읽기 -1.0% -6.3% -1.6% Fio-B:IOmeter-Intel File Server Access Pattern 대역폭-쓰기 -1.0% -6.3% -1.6% Postmark 워크로드 평균 대역폭 -8% 0% 3% Dbench 대역폭 측정 비교표 1.3% -39.9% -43.9% Compilebench 대역폭-Initial Create -17.0% 2.4% -15.4% Compilebench 대역폭-Compile -6.8% -6.8% -7.8% Compilebench 대역폭-Read Compile Tree 5.1% 1.6% 1.6% 지연시간 (작을수록 좋음) Fio-A:지연시간 최대 요청 크기 - SLQ:4MB, Others:512KB 5.9% 5.4% 5.8% Fio-A:지연시간 최대 요청 크기 - SLQ:4MB, Others:4MB 0.0% 0.1% 0.0% Fio-B:IOmeter-Intel File Server Access Pattern 지연시간-읽기 24% 17% 24% Fio-B:IOmeter-Intel File Server Access Pattern 지연시간-쓰기 -90% -80% -90% Blogbench 점수 Blogbench 워크로드 점수-읽기 8.7% 17.5% 15.5% Blogbench 워크로드 점수-쓰기 2.6% -12.3% 2.6%

9 SSD 버퍼 크기를 고려한 리눅스 입출력 스케줄러 성능분석 차이를 보이며, Blogbench는 읽기의 경우 디스패치 우선 순위 4MB에서 12.2% 20%, 쓰기의 경우 디스패치 우 선순위 0KB에서 58.8% 85.9%의 성능 점수 향상을 보여주었다. 워크로드 Dbench는 디스패치 우선순위 0KB에 서 42.9% 158.1%의 대역폭이 증가하였으며, Compilebench의 Initial Compile은 디스패치 우선순위 128KB에서 %의 대역폭 차이와 Read Compile Tree는 디스패치 우선순위 512KB에서 1.6% 5.1%의 대역폭 증가를 보이며 미묘하지만 워크로드에 따라 SSD의 버퍼크기도 영향이 있음을 보여 주었다. 여러 워크로드중 Dbench를 이용한 워크로드에서 디스 패치 우선순위를 0KB로 설정하고 실험한 결과에서 CFQ입출력 스케줄러와 비교했을 때 158.1%의 성능 향 상이 있었고 Blogbench를 이용한 워크로드에서 디스패 치 우선순위를 4KB로 설정하고 읽기 연산에서 CFQ와 비교했을 때 -65.5%로 성능 저하가 있었다. 이 결과로 보면 각각의 워크로드마다 많은 성능의 차 이를 보여주기 때문에 입출력 스케줄러를 설계할 때 일반 적인 읽기/쓰기의 성능 향상만 고려할게 아니라 컴퓨팅 환경과 사용하는 저장장치의 특성을 고려하여 입출력 스 케줄러를 설계해야 할 것이고 사용자 입장에서는 사용 환 경에 맞는 입출력 스케줄러를 선택해야 바람직 할 것으로 사료된다. 그리고 입출력 스케줄러에만 SSD의 버퍼크기만을 고 려하지 않고 다른 계층에서도 SSD의 버퍼 등의 다른 특 성들을 고려하여 설계해야 할 것으로 판단된다. Blogbench의 분석 결과를 보았을 때 Read와 Write 가 서로 상반되는 결과를 보았다. 이 논문의 실험 결과로 Read와 Write의 디스패치 우 선순위를 각각 나누어서 스케줄링을 하고, 현재의 부하에 따라 디스패치 우선순위가 동적으로 변경되는 기능이 필 요하다. 향후 여러 컴퓨팅 환경을 분석하여 사용되는 부하의 특징에 맞는 입출력 스케줄러의 연구와 PCI-E기반의 NVMe(Non-Volatile Memory Express) 스토리지에도 입출력 스케줄러를 적용하여 NVMe의 특징을 고려한 입 출력 스케줄링 방법, 그리고 멀티 프로세스들과 멀티코어 환경에 적합한 입출력 스케줄링을 연구해나갈 계획이다. 감사의 글 이 논문은 2013년도 중소기업청 구매 조건부 신제품 개발 사업의 연구비 지원에 의하여 연구되었음. 참 고 문 헌 [1] J. Kim, S. Seo, D. Jung, J. KIm, J. Huh, "Parameter-Aware I/O Management for Solid State Disks (SSDs)", in Proceedings of IEEE Transactions on Computers, pp May 2012 [2] J. Kim, Y. Oh, E.Kim, J. Choi, D. Lee, S. H. Noh, "Disk Scheduler for Solid State Drives", in EMSOFT '09: Proceedings of the seventh ACM international conference on Embedded software, pp Oct [3] M. Bjørling, J. Axboe D. Nellans, P. Bonnet, "Linux block IO: Introducing muti-queue SSD Access on multi-core System", in SYSTOR '13: Proceedings of the 6th International Systems and Storage Conference, No. 22, June 2013 [4] 김영주 김태석, "SSD의 특성을 활용한 리눅스 입출력 스케줄러의 구현", 한국 정보과학회 논문지, pp 년 10월 [5] D. P. Bovet, M. Cesati, Understanding the LINUX KERNEL, O'REILLY, pp , 2005 [6] S. Park, E. Seo, J. Shin, S. Maeng, J. Lee, "Exploiting Internal Parallelism of Flash-Based SSDs", in Proceedings of IEEE Computer Architecture Letters, pp. 9-12, Feb [7] S. Venkateswaran Essential Linux Device Drivers, Pearson Education, pp , 2008 [8] H. Kim, S. Ahn, "BPLRU: A buffer management scheme for improving random writes in flash storage", in FAST '08: Proceedings of the 6th USENIX Conference on File and Storage Technologies, pp Feb [9] S. Baek, S. Ahn, J. Choi, D. Lee, S. Noh, "Uniformity improving page allocation for flash memory file systems", in EMSOFT '07: Proceedings. of the 7th ACM & IEEE international conference on Embedded software, pp Oct [10] J. Lee, S. Kim, H. Kwon, C. Hyun, S. Ahn, J. Choi, D. Lee, S. Noh, "Block recycling schemes and their cost-based optimization in NAND flash memory based storage systems", in EMSOFT '07: Proceddings of the 7th ACM & IEEE international conference on Embedded software, pp Oct [11] L. Chang, "On efficient wear leveling for large-scale flash-memory storage systems", in SAC '07: Proceedings of the 2007 ACM symposium on Applied computing, pp , Mar [12] M. Dunn, A. L. N. Reddy "A New I/O Scheduler for Solid State Devices", Department of Electical and Computer Engineering, Texas A&M University, Feb [13] S. Park, E. Seo, J. Shin, S. Maeng, J. Lee "Exploiting Internal Parallelism of Flash-Based SSDs", in Proceedings of IEEE Computer Architecture Letters, pp. 9-12, June

10 컴퓨터정보통신연구 제22권 제2호 (7-16) [14] N. Agrawal, V. Prabhakaran, T. Wobber, J. D. Davis, M. Manasse, R. Panigrahy "Design Tradeoffs for SSD Performance", in ATC '08: Proceedings of the USENIX 2008 Annual Technical Conference on Annual Technical Conference, pp June 2008 [15] 염헌영, "SSD의 등장에 따른 OS의 변화" 전자공학학 회지, pp 년 5월 [16] Samsung Corporation. K9XXG08UXD Flash Memory Specification. [17] Marvell "88SS9187 Solid State Drive (SSD) Controller" [19] CodeCapsule.com, "Coding for SSDs", [Accessed on Apr. 2014] [20] H. Liu, "Linux I/O Schedulers", [Accessed on Apr. 2014] [21] J. Bell, "Operating Systems", [Accessed on Apr. 2014] [22] Postmark benchmark, [Accessed on Apr. 2014] [23] Blogbench, [Accessed on Apr. 2014] [24] Fio - Flexible IO Tester, [Accessed on Apr. 2014] [25] Compilebench, [Accessed on Apr. 2014] [26] Dbench, [Accessed on Apr. 2014] [27] Phoronix Test Suite, [Accessed on Apr. 2014] [28] Linux Kernel, [Accessed on Apr. 2014] 저 자 약 력 이승재 2009년 청주대학교 전자공학과 학사 2014년 충북대학교 컴퓨터과학과 석사 <주 관심분야 : 임베디드시스템, 운영체제, 플래시 메모 리, 안드로이드 플랫폼 등> 주영관 1999년 청주대학교 컴퓨터정보공학과 학사 2004년 충북대학교 전자계산학과 석사 2009년 충북대학교 전자계산학과 박사 충북대학교 전자정보대학 강사 <주 관심분야 : 임베디드시스템, 안드로이드 플랫폼, 클 라우드컴퓨팅 등> 전중남 1990년 연세대학교 전자공학과 공학 박사 1996~1998년 미국 Texas A&M 연구교수 현재 충북대학교 전자정보대학 교수 <주 관심분야 : 컴퓨터구조, 임베디드시스템>