Mobile App에서효율적인 storage접근 방법

장재영

Mobile Solution Development Group

0.시작하기 전

동기 & 목적

• 앱 개발자들이 flash memory의 I/O 동작을 이해하면 더 빠른 앱을 개발할 수

있을 것이라고 생각했습니다.

• 성능을 측정하고 I/O 동작의 분석을 통해 원인을 설명하는 방식으로 진행됩니

다.

• 최근에 출시된 또는 곧 만나게 될 flash memory를 소개하겠습니다.

• 설명을 위한 도표는 이해를 돕기 위해 간략하게 표현하였고, 이로 인해 다소

과장된 부분이 있을 수 있습니다.

Flash Memory Solution

smart phone

AP

storage

controller

NAND

Flash Memory

HOST

용량은 클 수록 더 빠르다

D0 D0 D1 D0 D1 D2 D3

× 4 write

1

2

3

4

1

2

1

x 1 x 2 x 4

SDP DDP QDP

SDP와 DDP 동작 차이

TIME

host

D0 D0

TIME

host

D0

D1

SDP DDP

처리 시간은

거의 같다.

R R

controller

flash

storage

controller

flash

storage

분석 방법

READ WRITE

TIME

devicelatency

host latency

devicelatency

performance

AP Storage

Analyzer

LBA, size, time

linux layer에 따른 성능

Storage

File System File System에 따라 성능 편차.

Block Layer I/O scheduler에 따라 성능 편차.

Device Layer H/W 사용 여부에 따라 성능 편

차.

Apps ?

1.App에서 어떻게I/O 성능을 개선시킬수 있을까?

Test Scenario

ZIP dummy.zip

dummy folder

압축 시간 측정

기대하는 host behavior

READ WRITEstorage READ WRITE

ZIPhost ZIP

TIME

NG

READ WRITEstorage READ WRITE

ZIPhost ZIP

TIME

Good

압축 앱 성능 test 결과

00:1600:26

01:20

0

20

40

60

80

100

A B C

A & B 앱 log 분석

storage

kernel

thread1 R

storage

kernel

app B ZIPR

thread2 R

thread3 R

ZIP

ZIP R

R

ZIP R

ZIP R

ZIP R

ZIP

app A

ZIPR ZIPR

2.Multi-Thread에 더 강한Command Queue

eMMC version history

eMMC 4.41

eMMC 4.5

eMMC 5.0 eMMC 5.1

0

100

200

300

400

500

2010 2011 2012 2013 2014 2015

MB

/s

CommandQueue

flagship model

NCQ (Native Command Queuing)

https://en.wikipedia.org/wiki/Native_Command_Queuing

Flash memory에서 CQ

HOST

W1 R2 R3 W4 R5 W6 Queue

R2 R3 R5 W1 W4 W6

Reordering

Flash Memory

CQ와 w/o CQ 동작 차이

TIME

queue

host R R

READ

R

READ

CQ

TIME

storage

host R

READ

w/o CQ R

READ

R

READ

READflash

storage

SDP와 QDP에서 CQ 동작 차이

QDP CQ

TIME

storage

host

qu

euei

ngSDP CQ

READREAD

READ

TIME

storage

host

READqu

euei

ng

Thread에 따른 CQ BM 결과

0.0

0.5

1.0

1.5

2.0

1 2 4 8

number of thread

4KB Random Read

0.0

0.5

1.0

1.5

2.0

1 2 4 8

number of thread

4KB Random Write

3.더 빠른 flash memoryUFS

eMMC & UFS 속도 spec

eMMC 4.41

eMMC 4.5

eMMC 5.0 eMMC 5.1

UFS 2.0HS-GEAR3

0

100

200

300

400

500

600

2010 2011 2012 2013 2014 2015

MB

/s

주요 interface 속도

0 100 200 300 400 500 600

LTE Category 10 DL

IEEE 802.11ac

SD card class 10

eMMC 5.0

USB 3.0

UFS 2.0 HS-GEAR3

MB/s

UFS에서 압축 앱 성능 test

00:1600:26

01:20

00:0900:17

00:36

0

20

40

60

80

100

A B C

eMMC UFS

eMMC는 Half, UFS는 Full

UFS

READ

WRITE

storage READ

WRITE

ZIPhost ZIP

TIME

READ

WRITE

ZIP

READ

WRITE

ZIP

READ WRITEstorage READ WRITE

ZIPhost ZIP

TIME

eMMC

READ READ

ZIP

eMMC는 Half, UFS는 Full

UFS

READ

WRITE

storage READ

WRITE

ZIPhost ZIP

TIME

READ

WRITE

ZIP

READ

WRITE

ZIP

READ WRITEstorage READ WRITE

ZIPhost ZIP

TIME

eMMC

READ READ

ZIP

eMMC, UFS 전송 방식 차이점

UFS

eMMCTIME

storage

host

TIME

storage

host

D0 D1 D2 D3

UFS, thread에 따른 BM 결과

0.0

2.0

4.0

6.0

8.0

1 4 8

number of thread

4KB Random Read

DDP QDP

0.0

2.0

4.0

6.0

8.0

1 4 8

number of thread

4KB Random Write

DDP QDP

eMMC, UFS의 CQ 동작 차이점

1. Read

2. Write

3. Delete

4. Read

5. Write

Host requestHOST eMMC

R1 W2

Wait

R4 W5

Delete3

HOST UFS

ALL

empty

4.C앱이 느린 이유Flush

C앱 log 분석

READ WRITEstorage

host

TIME

R ZIP W F

READ

R

FLUSH

storage

host

TIME

READ

R ZIP

READ

R ZIP

WRITE

W

app C

latency

READ

Rapp B

Flash memory에서 flush 동작

DATA

RAM

NAND

Flush

RAM

NAND NAND

RAM

Auto Flush

Flush CMD

NAND

RAM

시간적, 공간적 손해

TIME

host W W W

TIME

W F W F W F

storage

host

storage

Flush가 필요한 이유

1. Read

2. Write 0x02

3. Read 0x02

4. Read

5. Write

1. Read

2. Read 0x02

3. Read

4. Write 0x02

5. Write

Reorder

Old data가

읽혀짐

Barrier Command

W W WWF W W F F

RAM

RAM

NAND

RAM

NAND

NAND

W W WWB W W B B

G1 G2 G3

Keep an order

RAM NAND

RAM

SQLite의 write request 빈도

0%

20%

40%

60%

80%

100%

websurfing

camera facebook contacts file copy hangouts movieplayer

imageviewer

musicplayer

YouTube videorecording

Journal Meta SQLite Normal Data

SQLite의 chunk size 비율

0%

20%

40%

60%

80%

100%

websurfing

camera facebook contacts file copy hangouts movieplay

imageviewer

musicplay

YouTube videorecording

4KB 8KB 12~16KB 20~32KB 36~64KB 68~512KB

5.앞으로

Ecosystem

Linux Block IO: Introducing Multi-queue SSD Access on Multi-core Systems

Google’s project ARA

UFS

마치며

• 가능하면 multi-thread, flush는 필요할 때만.

• Ecosystem이 발전하면 더 빠른 I/O 환경이 구축.

• 효율적인 RAM 사용.

• 4K UHD 영상, VR 촬영으로 더 빠르고 많은 저장 공간 필요.

• 빠른 flash memory를 활용할 수 있는 앱도 있었으면...

Q&A

고맙습니다