02( ) CSTV16-12.hwp

Size: px

Start display at page:

Download "02( ) CSTV16-12.hwp"

예서 천
5 years ago
Views:

1 ISSN X(Print) / ISSN (Online) Journal of KIISE, Vol. 44, No. 3, pp , : 안드로이드스마트폰을위한통합된스토리지 I/O 분석도구 (: A Fully-Integrated Storage I/O Profiler for Android Smartphones) 한상욱 이인혁 류동욱 김지홍 (Sangwook Shane Hahn) (Inhyuk Yee) (Donguk Ryu) (Jihong Kim) 요약사용자경험이중요한스마트폰에서는사용자의입력에대한응용프로그램의반응시간에대한분석이필요하며특히사용자반응시간에큰영향을주는스토리지 I/O 성능의분석은사용자경험최적화를위한중요한요건이다. 사용자가경험하는반응시간의분석을위해서는입력을받아들이는최상위계층에서최하위저장장치계층을수직적으로아우르는통합된분석도구가필요한데기존의도구들은제한된범위의계층들에맞추어있어서효과적인사용자경험분석이어려운상황이다. 본논문에서는안드로이드스마트폰을대상으로최상위안드로이드플랫폼, 리눅스커널을포함하는전체스토리지 I/O 계층의 I/O 동작을측정하고, 이를바탕으로계층통합적분석을통하여각계층간 I/O 동작을연결하여사용자입력에따른스토리지 I/O 가미치는영향의분석이가능한도구인 를소개한다. 검증실험을통하여 가 0.1% 미만의동작부하로정확히분석할수있음을확인하였다. 키워드 : 데이터입출력분석도구, 안드로이드플랫폼분석도구, 리눅스커널분석도구 Abstract Application response time is critical to end-user response time in Android smartphones. Due to the plentiful resources of recent smartphones, storage I/O response time becomes a major key factor in application response time. However, existing storage I/O trace tools for Android and Linux give limited information only for a specific I/O layer which makes it difficult to combine I/O information from different I/O layers, because not helpful for application developer and researchers. In this paper, we propose a novel storage I/O trace tool for Android, called (Android I/O profiler). It traces storage I/O from application - Android platform - system call - virtual file system - native file system - page cache - block layer - SCSI layer and device driver. It then combines the storage I/O information from I/O layers by linking them with file information and physical address. Our evaluations of real smartphone usage scenarios and benchmarks show that can track storage I/O information from all I/O layers without any data loss under 0.1% system overheads. Keywords: I/O trace tool, Android platform I/O tracer, kernel I/O tracer, I/O visualizer 이연구를위해연구장비를지원하고공간을제공한서울대학교컴퓨터연구소에 논문접수 : 2016년 8월 18일 감사드립니다. 이논문은 2016년도정부 ( 미래창조과학부 ) 의재원으로한국연구재단의지원을받아수행된연구임 (NRF-2015M3C4A ) 이논문은 2016 한국컴퓨터종합학술대회에서 : 안드로이드스마트폰을 (Received 18 August 2016) 논문수정 : 2016년 11월 30일 (Revised 30 November 2016) 위한통합된스토리지 I/O 분석도구 의제목으로발표된논문을확장한것임 심사완료 : 2016년 12월 2일 학생회원 : 서울대학교컴퓨터공학부 (Accepted 2 December 2016) shanehahn@davinci.snu.ac.kr 비회원 : 서울대학교컴퓨터공학부 ihyee@davinci.snu.ac.kr 비회원 : 삼성전자소프트웨어연구소책임 du.ryu@samsung.com 종신회원 : 서울대학교컴퓨터공학부교수 (Seoul Nat'l Univ.) CopyrightC2017 한국정보과학회ː 개인목적이나교육목적인경우, 이저작물의전체또는일부에대한복사본혹은디지털사본의제작을허가합니다. 이때, 사본은상업적수단으로사용할수없으며첫페이지에본문구와출처를반드시명시해야합니다. 이외의목적으로복제, 배포, 출판, 전송등모든유형의사용행위를하는경우에대하여는사전에허가를얻고비용을지불해야합니다. 정보과학회논문지제44권제3호 ( ) jihong@davinci.snu.ac.kr (Corresponding author 임 )

: 안드로이드스마트폰을위한통합된스토리지 I/O 분석도구 233 1. 서론안드로이드스마트폰에서는사용자가응용프로그램을사용하면서느끼는사용자입력에대한응용프로그램의반응시간이사용자경험에큰영향을끼친다. 즉, 사용자경험이안드로이드스마트폰의성능에가장큰영향을주는요소이기때문에, 사용자중심의응용프로그램반응시간을결정하는요소들에대한분석이중요하다 [1].

2 : 안드로이드스마트폰을위한통합된스토리지 I/O 분석도구 서론안드로이드스마트폰에서는사용자가응용프로그램을사용하면서느끼는사용자입력에대한응용프로그램의반응시간이사용자경험에큰영향을끼친다. 즉, 사용자경험이안드로이드스마트폰의성능에가장큰영향을주는요소이기때문에, 사용자중심의응용프로그램반응시간을결정하는요소들에대한분석이중요하다 [1]. 응용프로그램반응시간은일반적으로크게응용프로그램수행시간 ( 유저레벨과커널레벨 ), 네트워크 I/O 수행시간그리고스토리지 I/O 수행시간으로구성된다. 안드로이드스마트폰의지속된성능향상으로인해응용프로그램수행시간이줄어들면서스토리지 I/O수행시간의비중이크게증가하고있다 [2,3]. 그림 1 은안드로이드스마트폰중하나인 Nexus 6에서 Gmail, Twitter, Facebook, Youtube, GTA 의시작시간중응용프로그램수행시간, 네트워크 I/O 수행시간, 스토리지 I/O 수행시간을보여준다. 그림 1에서알수있듯이, 스토리지 I/O 수행시간이응용프로그램런칭시간중많은시간을차지하는것을확인할수있다. 사용자경험에영향을주는응용프로그램반응시간을분석하기위해서는사용자가상호작용을하는응용프로그램수준의최상위계층에서부터데이터를저장하는저장장치를관리하는최하위저장장치계층까지스토리지 I/O에관여하는모든스토리지 I/O 계층을수직적으로아우르는통합된분석도구가필수적이다. 하지만기존의스토리지 I/O 분석도구들은커널의일부계층들에집중되어있기때문에 [4,5], 안드로이드프레임워크와커널을거쳐가는스토리지 I/O에대한통합된분석에는한계가있다. 본논문에서는사용자중심반응시간분석을위해사용자와응용프로그램의상호작용에서시작되는스토리지 I/O를최상위안드로이드프레임워크부터리눅스커널의저장장치드라이버까지스토리지 I/O에관여하는모든스토리지 I/O 계층에서실시간으로스토리지그림 1 응용프로그램시작시스토리지 I/O 시간비중 Fig. 1 Storage I/O time during application launching I/O 동작을관찰및분석하는통합된스토리지 I/O 분석도구인 를소개한다. 는기존안드로이드프레임워크와커널의동작을수정하지않고스토리지 I/O 각계층에서수집된정보만을바탕으로계층간연결고리를이용하여각계층의스토리지 I/O를이어서계층통합분석을가능하게한다. 또한 는사용자중심반응시간에영향을주지않도록고안되어다양한실험환경에서 0.1% 미만의무시할만한동작부하가발생하는것을확인할수있었다. 본논문의구성은다음과같다. 2장에서는안드로이드스마트폰의스토리지 I/O에대해프레임워크와커널의스토리지 I/O 계층과해당계층에서분석가능한 I/O 정보를소개한다. 3장에서는제안한통합된스토리지 I/O 분석도구인 의구조와동작원리에대하여설명한다. 4장에서다른 I/O 분석도구를사용하여 의동작을검증한다. 5장에서는제안한도구를사용하여다양한시나리오에서각스토리지 I/O 계층의부하를측정하고, 도구자체의동작부하를평가한다. 6장에서기존에존재하는스토리지 I/O 분석도구들을소개하고 7장에서결론을맺는다. 2. 안드로이드스마트폰의스토리지 I/O 안드로이드스마트폰의스토리지 I/O의부하를분석하기위해서는프레임워크부터저장장치까지스토리지 I/O 동작에관여하는계층을분석해야한다. 안드로이드플랫폼에서의스토리지 I/O 계층은프레임워크, Android Runtime (ART) 와여러종류의 Library들로구성된다. Library들중에서도 SQLite DBMS가스토리지 I/O에직접관여하기때문에, 스토리지 I/O 계층에포함되어있다. 리눅스커널의스토리지 I/O 계층은 Virtual File System과파일시스템들, Block Layer, SCSI Layer, 저장장치드라이버로구성되어있다. 저장장치드라이버는저장장치종류에따라 MMC, UFS 드라이버드라이버들로구성된다. 표 1은응용프로그램을포함한안드로이드플랫폼계층, Virtual File system을포함한파일시스템계층그리고 SCSI Layer와저장장치드라이버를포함한 Block Layer 계층에서분석가능한 I/O 정보를나타낸다. 응용프로그램과안드로이드플랫폼계층에서는 Read/Write 시스템콜을호출하여스토리지 I/O를수행하는데, 이때특정파일에접근하기위해서 FD (file descriptor) 를사용한다. 시스템콜로커널영역으로진입한스토리지 I/O는 FD로부터해당파일과관련메타데이터인 inode, dentry 정보를통해해당파일이위치한물리주소 (sector address) 를찾아내 Read/Write를수행하게된다.

3 234 정보과학회논문지제 44 권제 3 호 ( ) 표 1 I/O 계층별분석가능한스토리지 I/O 정보 Table 1 Analyzable Storage I/O Information for each storage I/O layers I/O Information Application File System Block Layer I/O Type I/O Size File Descriptor Ⅹ Process ID Sector Address Ⅹ 파일시스템의하위계층인 Block Layer부터는파일에대한정보를더이상유지하지않는다. 따라서, 시스템콜로요청된스토리지 I/O를저장장치드라이버계층까지연결지어분석하기위해서는모든계층에서공유할수있는고유한값의 I/O 정보가필요하다. 하지만, I/O type을제외하고는모든계층에서공유하는고유한값의 I/O 정보는존재하지않는다. I/O size의경우, 응용프로그램부터파일시스템까지는 byte 단위로관리되지만, Block Layer부터는 sector 단위 (512 byte) 로관리되기때문에모든계층에서공유하는고유한값으로사용할수없다. Process ID 역시 Buffered Write 처럼 Page Cache에서전달된스토리지 I/O의경우엔 Process ID가 0으로초기화되기때문에, 모든계층에서공유하는고유한값으로사용할수없다. 3. 설계및구현 는응용프로그램계층부터파일시스템계층까지 FD를연결고리로삼아서스토리지 I/O 정보를연결하고, 파일시스템계층부터저장장치드라이버계층까지물리주소로스토리지 I/O 정보를연결한다. 최종적으로모든스토리지 I/O 계층에서따로따로관찰된스토리지 I/O들을두개의연결고리를사용하여전부연결하는것이가능해지기때문에, 모든계층에서얻은 I/O 정보들중응용프로그램에서유발된스토리지 I/O를특정지어분석하는것이가능해진다. 는특정 I/O에특정변수를추가하여관련된모든함수및구조체를수정하는방식의 tagging과는달리, 각계층간의연결고리를이용하여모든스토리지 I/O 계층에서수집된정보들을통합및연결하여특정 I/O 정보를분석하는점에서기존의다른분석도구들과차별화된다. 3.1 설계그림 2는본논문에서제안한안드로이드스마트폰을위한통합된스토리지 I/O 분석도구인 의전체구조를나타낸그림이다. 안드로이드플랫폼과리눅스커널에구현된 I/O Profiler가각계층의스토리지 I/O 동작에대한정보를수집한뒤, 이를메인메모리에순환 그림 2 의전체구조 Fig. 2 Overall architecture of 표 2 가관찰하는 I/O 계층별함수목록 Table 2 s function lists of each I/O layers I/O Layer Read Write Application SYSCALL_DEFINE3 SYSCALL_DEFINE3 Virtual F/S generic_file_aio_read generic_file_aio_write Block Layer submit_bio / blk_done_softirq SCSI Layer scsi_request_fn / scsi_softirq_done Device Driver ufshcd_queuecommand / ufshcd_intr 버퍼에저장하여 Manager에게전달한다. Manager는각계층의스토리지 I/O 정보를연결하여사용자와응용프로그램간의상호작용으로발생한스토리지 I/O를계층통합적분석이가능하게한다. 또한, Manager는사용자가스토리지 I/O에대한정보를다각도에서분석할수있게끔 DB에입력이가능한 CSV 파일형식이나 wave viewer를사용가능한 waveform 파일형식으로출력해주는기능도제공한다. I/O Profiler는모든스토리지 I/O 계층에구현되었는데, 그림 2에서는표 1과같이크게 3가지계층으로분류하였고, 이는각계층에서얻을수있는스토리지 I/O 정보의범위에따라결정되었다. Android I/O Profiler 에서는스토리지 I/O를유발한응용프로그램의 Unique identifier, Process identifier, Thread identifier 정보와파일이름, 크기, 오프셋정보를저장한다. File I/O Profiler에서는파일이름, 크기, 오프셋외에파일시스템의정보를활용하여파일의물리주소인 sector address를저장한다. Block I/O Profiler에서는파일이저장되는블록저장장치에관련된정보와파일의물리주소를저장하게된다. 또한, 각계층에서스토리지 I/O 동작에소요되는시간도저장한다. 표 2는 가각스토리지 I/O 계층에서관찰하는함수들을나타낸다. 응용프로그램계층부터파일시스템계층까지 Read/Write는각기다른함수가담당하여스토리지 I/O를처리하지만, Block Layer부터는같은함수에서 Read/Write 모두가처리한다. 또한, Block Layer부터는저장장치에스토리지 I/O를전달하는함수

4 : 안드로이드스마트폰을위한통합된스토리지 I/O 분석도구 235 와저장장치로부터스토리지 I/O 처리종료를알리는인터럽트가전달받아수행하는인터럽트핸들러함수를모두관찰하여스토리지 I/O 정보를수집한다. 3.2 구현 는스토리지 I/O 동작에관여하는함수들의파라미터와파일과블록 I/O 구조체로부터스토리지 I/O 정보를얻는방식으로구현되었기때문에, 의동작을위해서기존함수들이나구조체들의수정이필요하지않다. Manager는 의동작이안드로이드스마트폰성능에영향을주지않도록각 Profiler로부터전달받은각계층의스토리지 I/O 정보를모두메인메모리에순환버퍼형태로저장하였다가, 사용자에의해 동작이종료되면사용자가지정한파일형식으로분석된스토리지 I/O 정보를저장하게된다. 멀티코어 CPU 환경에서는하나이상의쓰레드가동시에순환버퍼에접근하여 I/O 정보를기록하는경우가발생하는데, 순환버퍼에 Lock을사용하면안드로이드스마트폰성능저하가발생하기에, Manager는 CPU 코어수만큼별도로생성해둔예비순환버퍼에 I/O 정보를저장하도록쓰레드들을유도하여성능저하를최소화하였다. 순환버퍼가메인메모리에서사용하는공간은최대 50 MB로다른응용프로그램의동작에지장을주지않을정도크기로할당하고있다. Manager는가공된스토리지 I/O 정보를 DB 형식혹은 Waveform 형식의파일출력을지원함으로써사용자의분석의용이성을높이도록구현되었다. 그림 3 은 를이용하여분석한스토리지 I/O 정보를 Waveform 파일로출력하여 GTKWave[6] 라는프로그램을통해 Visualization한결과를나타낸화면이다. 리눅스커널의최상위계층인 Virtual File System부터최하위계층인저장장치드라이버까지시간에따라스토리지 I/O가어떤계층의어떤함수에서얼마나동작부하 가발생하였는지한눈에파악이가능하게해준다. 이는스토리지 I/O 분석을통한스토리지 I/O 성능최적화연구에 가유용하게사용될것으로기대한다. 4. 검증 의동작을검증하기위해, 기존에존재하고널리쓰이는 2개의 I/O tracer 프로그램인 strace와 blktrace를사용하였다. strace는명령어로설정한특정 PID(Process ID) 에서발생되는시스템콜을수집한다. blktrace는 Block layer에서의스토리지 I/O 처리과정을수집한다. blktrace는 Linux kernel가지원하는 trace 도구이다. strace는 Linux kernel에는포함되어있지는않지만, strace와 blktrace 모두 kernel의 configuration을수정하면간단히실행할수있도록 Linux에서지원하고있다. 그림 4, 그림 5와그림 6은안드로이드스마트폰으로사진을찍으면서각각, strace와 blktrace로수집한로그를나타낸화면이다. 그림 5에서나타나듯이, FD가 55인파일을 8192 byte 크기만큼읽으라는시스템콜이호출된것을확인할수있다. 이는표 3을보면, 는 read 시스템콜을 400번함수로로그를남기고있기때문에, 그림 4에서도확인할수있다. 마찬가지로 blktrace의결과화면인그림 6을보면물리주소가 이고크기가 8 KB(1 sector가 512 byte이기때문에, 16 sector는 8 KB이다.) 인 Read Block I/O가 초에 Queue(Q) 된것을확인할수있다. 또한해당주소의 Block I/O가 초에 Complete(C) 된것을확인할수있는데, 이는표 4에서따르면, 는 Block I/O queue가 700번으로 Block I/O complete은 710번으로로그를남기고있고, 그림 4에서 700번과 710번이같은시간차를두고발생하는것을확인할수있다. 그림 4 의 log 예시 Fig. 4 Snapshot of s log 그림 5 strace 의 log 예시 Fig. 5 Snapshot of strace s log 그림 3 와 GTKWave 를이용한 I/O 동작 Visualization Fig. 3 Storage I/O visualization using and GTKwave 그림 6 blktrace 의 log 예시 Fig. 6 Snapshot of blktrace s log

5 236 정보과학회논문지제 44 권제 3 호 ( ) 표 3 특정 I/O event에대한 strace와 의표기 Table 3 Predefined symbols of and strace for read/write system call I/O event strace Read System Call read 400 Write System Call write 410 표 4 특정 I/O event에대한 blktrace와 의표기 Table 4 Predefined symbols of and blktrace for read/write system call I/O event blktrace Block I/O Queue Q 700 Block I/O Complete C 710 하지만그림 4, 그림 5 그리고그림 6을보면로그에표시된시작시간이다다른것을확인할수있는데이는 3가지다수집할때판단하는현재시각에대한기준이다르기때문이다. 는 System이 booting된순간부터흘러간시간을현재시각으로측정하고있고, strace는현지시각을현재시각으로측정하고있고, blktrace는 blktrace를수행하기시작한순간부터흘러간시간을현재시각으로측정하고있기때문이다. 따라서 를 strace와 blktrace로검증할때시간은각스토리지 I/O 간의상대시간을기준으로검증하였다. 6개의안드로이드스마트폰사용시나리오를대상으로 blktrace를사용하여 를검증을수행하였다. ( 각시나리오의자세한정보는표 5에나타나있다.) strace는 strace 수행조건때문에파일내부복사시나리오만대상으로검증을진행하였다. 정확한검증을위해 를먼저시작하고, strace와 blktrace를시작한뒤, 특정안드로이드스마트폰사용시나리오를수행한뒤, strace와 blktrace를종료시키고, 를가장나중에종료시켰다. 6개의시나리오를위의방법으로수행한뒤, strace와 blktrace에서나타난로그가 에존재하는지확인하는간단한스크립트를작성하여분석한결과, 표 6과표 7에서나타나듯이 strace의모든 read/write 시스템콜과 blktrace의모든 block I/O 표 6 strace 와 로그비교 Table 6 A comparison between strace and Scenario strace read read strace write write Internal File Copy 표 7 blktrace 와 로그비교 Table 7 A comparison between blktrace and Scenario blktrace queue queue blktrace complete complete Application Launch Web Browser Camera Download Internal File Copy USB File Copy queue/complete가 에하나도빠짐없이나타나는것을확인할수있었다. 5. 실험결과 제안한분석도구의정확성을판단하기위해본논문에서는안드로이드프레임워크버전 5.0과리눅스커널버전 에 를구현하여해당버전의프레임워크와커널을지원하는안드로이드스마트폰에뮬레이션보드에서 의계층별스토리지 I/O 동작부하를측정하고 자체동작부하를검증하는실험을진행하였다. 안드로이드스마트폰의 I/O 계층별부하를측정하기위해어플리케이션을실행하는시나리오, 카메라연속촬영시나리오, 외부에서 USB를통해스마트폰저장장치로파일을복사하는시나리오와스마트폰저장장치의파일을다른디렉토리에복사하는시나리오를수행하면서 를통해계층별스토리지 I/O 동작부하를 표 5 검증을위한안드로이드사용시나리오 Table 5 Scenarios used for verification Scenario Name Scenario Explanation Application Launch Launching 3D game application Web Browser Loading multiple web pages Camera Camera burst shot (30 photos) Download Downloading 1 GB file Internal File Copy 1 GB file internal copy USB File Copy 1 GB file USB copy 그림 7 로측정한각시나리오별계층별스토리지 I/O 동작부하 Fig. 7 Measured operation latencies for each storage I/O layer using

: 안드로이드스마트폰을위한통합된스토리지 I/O 분석도구 237 측정하였다. 그림 7은계층별스토리지 I/O 동작부하를측정한결과이며, 대부분의경우파일시스템과 Block Layer에서의부하가평균 50% 이상을차지하는것을확인할수있었다. 또한, 어플리케이션실행시나리오에서는어플리케이션이최대 27% 까지동작부하를차지하는것을확인할수있었다.

관련연구리눅스커널의스토리지 I/O를분석하는도구는 Virtual File System으로인가되는시스템콜을분석하는 strace[4], 그리고 Block Layer 내부의스토리지 I/O 를분석하는 blktrace[5] 가존재한다. 그러나이두도구를모두사용한다고해도사용자와응용프로그램의상호작용에서시작된스토리지 I/O가무엇인지커널수준의정보로는파악이불가능한한계가존재한다.

6 : 안드로이드스마트폰을위한통합된스토리지 I/O 분석도구 237 측정하였다. 그림 7은계층별스토리지 I/O 동작부하를측정한결과이며, 대부분의경우파일시스템과 Block Layer에서의부하가평균 50% 이상을차지하는것을확인할수있었다. 또한, 어플리케이션실행시나리오에서는어플리케이션이최대 27% 까지동작부하를차지하는것을확인할수있었다. 자체의동작부하를검증하기위해 Androbench, Antutu, Storebench 벤치마크프로그램들에대해서 를사용하는경우와사용하지않는경우에수행시간을측정하여비교하는실험을진행하였다. 실험결과, 를사용하는경우와사용하지않는경우의수행시간차이가평균 0.1% 미만으로매우적은동작부하를발생하는것을확인하였다. 6. 관련연구리눅스커널의스토리지 I/O를분석하는도구는 Virtual File System으로인가되는시스템콜을분석하는 strace[4], 그리고 Block Layer 내부의스토리지 I/O 를분석하는 blktrace[5] 가존재한다. 그러나이두도구를모두사용한다고해도사용자와응용프로그램의상호작용에서시작된스토리지 I/O가무엇인지커널수준의정보로는파악이불가능한한계가존재한다. 또한, 두도구의정보를바탕으로스토리지 I/O를연결하는작업이불가능한데, 시스템콜의정보에는파일에대한정보가있지만, Block Layer에는파일에대한정보가존재하지않기때문이다. 안드로이드스마트폰환경에서이러한한계를극복하기위해 Androtrace[7] 가기존에제안되었다. Androtrace 는파일의이름을바탕으로커널수준에서 SQLite의스토리지 I/O를파악하여 Block Layer까지분석하는도구이다. 이는기존 strace와 blktrace의한계를넘어서는발전된스토리지 I/O 분석도구이지만, 여전히사용자와직접상호작용하는응용프로그램수준의스토리지 I/O 정보를파악하기위해서는안드로이드프레임워크의분석이추가로필요하다. 또한, 데이터의입출력을수행하는저장장치까지스토리지 I/O가거치는계층중 SCSI Layer와저장장치드라이버를분석하고있지않기때문에, 해당계층의스토리지 I/O 분석은불가능하다는한계가존재한다. 반면, 는최상위계층인프레임워크부터최하위계층인저장장치드라이버까지스토리지 I/O 정보를분석함으로써기존분석도구대비차별화되는장점을보인다. 지 I/O의부하를정밀분석하는통합된스토리지 I/O 분석도구인 를제안하였다. 개발된도구는응용프로그램으로부터발생된스토리지 I/O를프레임워크부터저장장치드라이버까지모든소프트웨어계층별로스토리지 I/O 정보를수집및연결하여각계층별부하에대한계층통합적분석을가능하게해준다. 본도구를활용하면안드로이드스마트폰에서의스토리지 I/O 성능최적화연구에많은기여가있을것으로예상된다. References [1] W. Song et al., "Reducing Energy Consumption of Smartphones Using User-Perceived Response Time Analysis," Proc. International Workshop on Mobile Computing Systems and Applications, No. 20, [2] H. Kim et al., "Revisiting Storage for Smartphones," Proc. USENIX Conference on File and Storage Technologies, No. 14, [3] D.T. Nguyen et al., "Improving Smartphone Responsiveness through I/O Optimizations," Proc. ACM International Joint Conference on Pervasive and Ubiquitous Computing, pp , [4] strace. [Online]. Available: 1/strace. [5] blktrace. [Online]. Available: 8/blktrace. [6] GTKWave. [Online]. Available: [7] E. Lim et al., "Androtrace: framework for tracing and analyzing IOs on Android," Proc. Workshop on Interactions of NVM/FLASH with Operating Systems and Workloads, No. 3, 한상욱 2011년 KAIST 전산학학사. 2013년서울대학교컴퓨터공학부석사. 2013년~ 현재서울대학교컴퓨터공학부박사과정관심분야는플래시저장장치, 임베디드소프트웨어, 모바일시스템, 운영체제 이인혁 2015년한양대학교컴퓨터공학부학사 2017년서울대학교컴퓨터공학부석사관심분야는임베디드소프트웨어, 모바일시스템, 운영체제 7. 결론 본논문에서는안드로이드스마트폰의사용자경험에큰영향을주는응용프로그램의반응시간중스토리

관심분야는임베디드소프트웨어, 모바일시스템, 저전력시스템 김지홍 1986년서울대학교계산통계학과학사 1988년 University of

7 238 정보과학회논문지제 44 권제 3 호 ( ) 류동욱 2012 년성균관대학교 DMC 공학과석사 2012 년 ~ 현재삼성전자소프트웨어연구소책임연구원. 관심분야는임베디드소프트웨어, 모바일시스템, 저전력시스템 김지홍 1986년서울대학교계산통계학과학사 1988년 University of Washington 컴퓨터과학과석사. 1995년 University of Washington 컴퓨터과학및공학과박사. 1995년~1997년미국 Texas Instruments 선임연구원. 1997년~현재서울대학교컴퓨터공학과교수. 관심분야는플래시저장장치, 저전력시스템, 임베디드소프트웨어, 컴퓨터구조

6.24-9년 6월

6.24-9년 6월 리눅스 환경에서Solid-State Disk 성능 최적화를 위한 디스크 입출력요구 변환 계층 김태웅 류준길 박찬익 Taewoong Kim Junkil Ryu Chanik Park 포항공과대학교 컴퓨터공학과 {ehoto, lancer, cipark}@postech.ac.kr 요약 SSD(Solid-State Disk)는 여러 개의 낸드 플래시 메모리들로 구성된