Improving JFFS 2 RAM usage and performance Alexey

Improving JFFS 2 RAM usage and performance Alexey Korolev ELC Europe 2007

Agenda • • JFFS 2 in brief • Improving JFFS 2 RAM usage and performance within existing architecture JFFS 2 efficiency on large volumes – Market data on flash densities – Volume size test data – Why JFFS 2 is inefficient on large volumes – Proposed improvement – File direct I/O as a fast solution to reduce RAM usage and increase performance – Test data – Requirements and limitations – Current status and availability – Deferred write and JFFS 2 RAM buffer as a RAM usage reduction prototype • Q&A Verdana regular 7 pt. Legal text goes here Flash Products Group

JFFS 2 in brief • • • Journaling Flash File System version 2 • Widely used in many configurations to provide FS interface to memory technology devices. Supported in Linux for years since 2001. Works with NOR, NOR-ECC, NOR with programming regions, NAND and Dataflash Verdana regular 7 pt. Legal text goes here Flash Products Group

Forecasted Flash Densities Cellular Handsets Forecasted NOR and NAND Densities in MB 2007 Verdana regular 7 pt. Legal text goes here Flash Products Group 2008 2009 2010 NOR 25. 8 31. 5 40. 2 48. 8 NAND 46 79 146 239

JFFS 2 RAM usage (MB) Volume size test data Volume used size (MB) Verdana regular 7 pt. Legal text goes here Flash Products Group

File open time (sec) Volume size test data File size (MB) Verdana regular 7 pt. Legal text goes here Flash Products Group

Why Does JFFS 2 Become Inefficient on Large Data Volumes? JFFS 2 assumes keeping nodes (fragment) descriptions in memory since the moment of getting file info. 1. JFFS 2 RAM usage increases linearly as the number of nodes increases (Every data node takes 40 bytes of RAM) 2. If a file has many fragments, file open time increases significantly because JFFS 2 needs to read every header from flash This is the architectural scalability issue of JFFS 2 It is not possible to completely solve it without a complete file system redesign, however there are workarounds Verdana regular 7 pt. Legal text goes here Flash Products Group

Improving RAM Usage and File Open Time Within Existing JFFS 2 Architecture Our approach to reducing RAM usage and decreasing file open time is conceptually simple (but effective): Reduce the number of JFFS 2 fragments Let’s look at how this can be done… Verdana regular 7 pt. Legal text goes here Flash Products Group

Using File Direct I/O to Reduce RAM Usage and Increase Performance Lets look at the file write procedure Application requests to write data 64 KB JFFS 2 file_ops. write() V F S do_sync_write() add to VFS pg cache 0 -4 KB JFFS 2 write_page() 4 -8 KB … 56 -64 KB Flash Products Group 16 requests 16 fragments

Using File Direct I/O to Reduce RAM Usage and Increase Performance One way to reduce number of nodes (fragments) is to provide direct file IO interface support in JFFS 2 and increase JFFS 2 granularity Application requests to write data 64 KB Flash Products Group JFFS 2 file_ops. write() V F S Write one fragment of data

Test Results JFFS 2 RAM usage (MB) JFFS 2 RAM Usage for Different Volume Sizes 3. 5 X Verdana regular 7 pt. Legal text goes here Flash Products Group Volume Size

Test Results Stat Time(sec) Stat Time Performance for Different File Sizes >4 X File Size (MB) Verdana regular 7 pt. Legal text goes here Flash Products Group

Requirements and Limitations • Application should write data in large chunks • If applications write data in small chunks, fragments won’t be combined until garbage collector touches it • This model not effective if there are tons of tiny files • Avoiding VFS page cache use could have positive and negative consequences • Using the file open flag is recommended* • For media files it avoids wasting page cache space and this could positively affect on system performance • For databases, logs, and documents, using the page cache is highly recommended Verdanaproviding regular 7 pt. * We have patch reading through VFS cache while direct write Legal text goes here Flash Products Group

Current status and availability • The File direct I/O feature is ready for use (Linux 2. 6. 20) • It can be downloaded from www. sourceforge. net/mtd -mods • The patch size is <50 Kb and can be easily ported to other JFFS 2 versions Verdana regular 7 pt. Legal text goes here Flash Products Group

Deferred Write and RAM Buffer as a RAM Usage Reduction Prototype Compared to Direct IO, deferred write is effective even if applications write data in small chunks. JFFS 2 file_ops. write() Application requests to write data 6 KB 1 KB do_sync_write() V F S 4 KB 2 KB 4 KB 1 KB … … Sync() Verdana regular 7 pt. Legal text goes here Flash Products Group JFFS 2 Write RAM buffer JFFS 2 flush RAM buffer Merge nodes Large chunks

Conclusion Patches to provide Direct I/O in JFFS 2 are ready + Significantly reduce RAM usage and open time + Easy applicable - Has restrictions on large write chunks Verdana regular 7 pt. Legal text goes here Flash Products Group 16

Q&A Questions ? Link: http: //sourceforge. net/mtd-mods mailto: alexey. korolev@intel. com Intel Confidential Flash Products Group 17