Flash Memory Based Bottom Up Analysis for Smart Phone System 목 차 1. Background 2. Controller & Driver Layer 3. File System Layer 4. DB Layer 5. Summary 2012. 10. 16 LG Electronics / Mobile Communications Company
1. Background Why Flash Memory is Important? Application Processor 및 Main Memory의 Speed를 Flash Memory가따라가지못하고있는상황 Android Platform Application Applications Framework Active Manager CPU/ Working Memory/ Flash Memory Bandwidths Gap NAND Flash 의낮은 B/W 성능이 System 성능저하요인 (Booting, Web Browsing, App 실행및저장속도등 ) Lib & HAL Layer Linux Kernel B D SQLite Flash Memory driver Scheduler Webkit Block Device Etc. File System C Memory B/W Hierarchy CPU L2 Cache Main Memory Storage AP Very High Speed (~32 GB/s) High Speed (12.8 GB/s) Low Speed (0.1 ~ 0.3 GB/s) A emmc Controller
2. Controller & Driver Layer Flash Memory Performance Effect on Android System Application 특성마다 Bandwidth (Sequential) 혹은 IOPS (Random) 의 Dependency 를가짐 Android 의특성상 IOPS 의성능이 System 전체성능에 Critical 한요소로인식됨 A IOPS Multitasking USB Download MB/S Full HD Recode Browsing Boot Photo Video Recode Email Alarm Music Video Playback 0.5KB Random Sequential 128KB Source form : SanDisk Presentation July 2011 Modified by LGE
2. Controller & Driver Layer Performance Gap in Flash Memory emmc Memory 의 Performance Gap 이발생하는이유? A 동일 H/W Platform 상에서 Flash Memory 만교채후 Test Browsing Speed BMT Test Result Inside of emmc Flash Controller 120 100 Flash ROM Flash RAM 80 Flash Controller Role Cold Low Level Driver 60 Worm FTL (Flash Transition Layer) 1 Block Replacement (Address Translation Table) AVG 40 2 Dynamic Wear - leveling li 3 Garbage Collection 4 Error Detection & Correction 20 0 A사 B사 C사 Browsing BMT Test on Android System (10 Times Ave.) Android Gingerbread Version Flash Controller Performance itself: Sequential FTL Algorithm : Random emmc 성능의가장큰원인은 FTL!!
2. Controller & Driver Layer How to Increase Flash Memory Performance A B Flash Memory 의 Performance 를증가시키기위한방법? Well-Known Approach 1 I/O : Data s path increase [Multi-I/O] 2 Page size : Buffer size to program at once. 3 Interleave : Hide program operation by using long program time. 4 FTL algorithm 5 Physical Bandwidth - Bus width & Frequency - DDR More.. 1 SLC Buffer and/or SRAM Cache XX% of User Data Area - Low Power Serial Bus (UFS) 2 New Command MLC Area User Data Area and GP Area SLC Buffer Second Access First Access Legacy Command Packed Command (emmc4.5) Command Queuing Multi- I/O Page Size Interleave (UFS) Source form : Toshiba Presentation Material
3. File System Layer File System in Android Smart Phone C File System 에의한 System Performance File System EXT4 Vs BtrFS (Googling Result) System Call Interface VFS (Virtual File System) EXT4 현재 Linux 에서범용적으로쓰이는기본 File System 기존의 Ext3 를기반으로향상시킨 File System BtrFS Metadata와 data관리에 B-tree를사용한 Advanced File System 기존의 File System 과다른방식으로개발된 File System EXT/3/4 BtrFS RFS XFS JFFS2 YAFFS2 LogFS UBIFS inode 의선할당으로인한전체용량의 1.5% 정도낭비발생 작은파일에대한 I/O 성능이좋아 Embedded 환경에유리 (Booting Time 향상 ) Block Device MTD Device & API (Memory Technology Device) 부분적인 Error Free 제공 (File System의중요부분인 Metadata의깨짐만보호 ) Snapshot 지원을통한완전한 Error Free 제공 FTL 실제 BtrFS로 File System변경후 대용량 Memory HDD NAND NOR One Data NAND Flash -Module 반응속도Check BMT 결과는 EXT4가우세함 File System structure 향후결과는?
3. File System Layer File System in Android Smart Phone C File System Journaling 에의한 System Performance Effect Journaling 비정상적인종료로인한, 파일시스템손상을최소화하기위함 오랜시간이걸리는 fsck 1) 를사용하는기존파일시스템의문제점을해결하기위해고안 Journal 을관리하는방법으로 file system 손상을피함 Metadata Journaling mode 속성정보, data를정의하고설명해주는 data. Data의종류에따라 metadata 정보가달라질수있음. [ 사진 metadata] < Ordered > -카메라모델명 -촬영일자 -렌즈 - 조리개값 & 셔터스피드 -초점거리 & 측광방식 -해상도 [ 파일 metadata] -파일위치 -크기 -소유자 -권한 -시간정보 < Writeback > Data integrity : 최저 Data 복구율매우낮음 XFS file system의기본설정 비정상종료시 - metadata 보존 -data손실가능 < Ordered > Data integrity i : 중간 < Journal > Ext4 file system의기본설정 비정상종료시 - metadata 가 journal 에기록되지않게되는경우 data 손실가능 Data integrity : 최고 Metadata 와 data 를두번저장하여성능저하발생 1) File system check : file system이비정상적으로종료되면, 운영체제가이를감지해수행하는검사.
3. File System Layer File System in Android Smart Phone C File System Journaling 에의한 System Performance 향상 Test [Journaling On/Off 에의한 Performance 성능향상도측정 ] 설정 Data 영역 partition 실행후, journaling off option 실행. @ android/device/.../format_disk/format_first.sh /system/bin/mke2fs t ext4 b 4096 /dev/block/mmcblk0p28 /system/bin/tune2fs O ^has_journal /dev/block/mmcblk0p28 Test Result [Dual Core/ICS Version/ AndroBench/ 16GBtye/ emmc 4.41] 80.00 60.00 40.00 % 20.0000 0.00-20.00 4 8 16 32 64 128 256 Sequencial_read Sequencial_write Random_read Random_write Data(KB) Journaling off 시 Read 에대한약간의성능저하가있으나 write 에대한성능향상이월등히좋음.
3. File System Layer File System in Android Smart Phone C Mount Option 에의한 System Performance 향상 noatime atime 이 set 되어있는경우 read 만하는경우에도 inode 의 acces 에의한 update 발생하여 emmc write 가됨. noatime 이 set 될경우 file 의 change/ write 시에만 access time 이 update 되므로 performance 향상효과가발생. journal_async_commit delalloc nodelalloc Block allocation 을매번 write 시하지않고 delay 하고있다가, 나중에 disk 에 write 해야하는순간에 allocation 함. Sequential write 인경우에특히효과를볼수있고, Data fragmentation 또한방지할수있음. Test Result [Dual Core/ICS Version/ filebench] 60000 내부적으로 journal_checksum 함께 enable 함. revoke & descriptor block의 write가완료하는동안 commit block의 write 가함께이루어지게되어 (asynchronous 하게동작 ) 나중에 50000 commit block의 write가완료될때까지따로 blocking wait 할필요가없기때문에 performance 좋아짐. (parallel) 40000 Original Transaction Journal_ async _ commit Transaction 30000 descript or metada ta Commit descript or metada ta Commit 20000 Write ordering Descriptor & data write 완료후 commit block submit (sync) Write ordering Descriptor & data write 후 wait 하지않고 commit block write (async) 10000 0 SeqRd SeqW RandRd RandW Default noatime journal_async_commit _ delalloc & noauto_da_alloc
4. DB Layer DB in Android Smart Phone D DB Journaling 에의한 System Performance Effect DB Kernel Android Platform User Process A Journal File System [EXT4] Buffer Cache Block I/O layer ( I/O sched / device driver) emmc interface (Device Driver) User Process B 기존 Page : 4KB/Sector : 512Byte Page = Sector= 4KByte [Meta Data 및실제 Data] Journal [Meta Data Only] 1 2 3 DB DB DB DB 변경 journal 원본 backup journal journal Journal 삭제 DB Journaling Off 를하기위한조건 DB의무결성보장을위해 journal 파일을사용 Journal file 에대한생성, 쓰기, 삭제로인한별도 I/O overhead 발생 어떠한조건을만족해야 2번, 3번항목처럼 DB만변경할수있을까? 1. DB 의 Page Size 가 Sector Size 와동일할것 2. Database 의 Page 수정이단하나의 Database Page 에서만발생할것 3. Sector Write 가 Atomic Operation 이어야할것 1 번 2 번항목은 DB 의수정으로간단히해결 3 번항목은 File System 과 Flash Memory 에서많은검증필요 FTL emmc Flash Controller Flash Chipset Page 단위 [16KByte] Reliable Write 단위는가변적
5. Summary Summary Application Android Platform Applications A Flash Memory itself 1. 각업체마다, 사용되는 emmc Controller 가상이함 2. 이로인한 FTL차이로인하여 IOPS의편차발생 3. Flash Memory 성능을높이기위한여러가지 Technology 가시도되고있음 (Ex. Interleave, Multi-I/O, Low Power Serial Bus [UFS] 등 ) Framework Lib & HAL Layer Linux Kernel B D Flash Memory driver Active Manager SQLite Webkit Etc. Scheduler Block Device File System C B C Flash Memory Driver 1. emmc 의 Version Up 되면서성능향상을위한여러가지 Feature 및 Command가새로이추가됨 (Ex. emmc4.5 HS200, Packed/Discard Command) (Ex. UFS Command Queuing) File System 1. EXT4 File System이외에도 BtrFS를주목해야함 2. Journaling에의한 System Performance 저하 - File System의 Journaling Off시키면 20% 정도성능향상 (Embedded Battery System에적합 ) 3. File System Mount Option 선택만잘해도 10% 정도성능향상 A emmc Controller D DB 1. Journaling에의한 System Performance 저하 - File System 의 Journaling Off 시키면 40% 정도성능향상 (Full Journaling이기때문 ) 2. DB 에서 Journaling Off 하기위한조건은까다로우며많은 Test필요함 And More.
Q&A