Improving JFFS2 RAM usage and performance

1
Improving JFFS2 RAM usage and performance
Alexey Korolev

• ELC Europe 2007

2
Agenda

• JFFS2 in brief
• JFFS2 efficiency on large volumes
• Market data on flash densities
• Volume size test data
• Why JFFS2 is inefficient on large volumes
• Improving JFFS2 RAM usage and performance within
  existing architecture
• 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 JFFS2 RAM buffer as a RAM
  usage reduction prototype
• QA

3
JFFS2 in brief

• Journaling Flash File System version 2
• Supported in Linux for years since 2001.
• Works with NOR, NOR-ECC, NOR with programming
  regions, NAND and Dataflash
• Widely used in many configurations to provide FS
  interface to memory technology devices.

4
Forecasted Flash Densities
Cellular Handsets Forecasted NOR and NAND
Densities in MB
5
Volume size test data
JFFS2 RAM usage (MB)
Volume used size (MB)
6
Volume size test data
File open time (sec)
File size (MB)
7
Why Does JFFS2 Become Inefficient on Large Data
Volumes?

• JFFS2 assumes keeping nodes (fragment)
  descriptions in memory since the moment of
  getting file info.
• JFFS2 RAM usage increases linearly as the number
  of nodes increases (Every data node takes 40bytes
  of RAM)
• If a file has many fragments, file open time
  increases significantly because JFFS2 needs to
  read every header from flash
• This is the architectural scalability issue of
  JFFS2
• It is not possible to completely solve it without
  a complete file system redesign, however there
  are workarounds

8
Improving RAM Usage and File Open Time Within
Existing JFFS2 Architecture

• Our approach to reducing RAM usage and decreasing
  file open time is conceptually simple (but
  effective)
• Reduce the number of JFFS2 fragments

Lets look at how this can be done
9
Using File Direct I/O to Reduce RAM Usage and
Increase Performance
Lets look at the file write procedure
Application requests to write data
do_sync_write()
64KB
JFFS2 write_page()
16 requests 16 fragments
10
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
  JFFS2 and increase JFFS2 granularity

Application requests to write data
V F S
64KB
Write one fragment of data
11
Test Results

• JFFS2 RAM Usage for Different Volume Sizes

JFFS2 RAM usage (MB)
3.5X
Volume Size
12
Test Results

• Stat Time Performance for Different File Sizes

Stat Time(sec)
gt4X
File Size (MB)
13
Requirements and Limitations

• Application should write data in large chunks
• If applications write data in small chunks,
  fragments wont 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

We have patch providing reading through VFS
cache while direct write
14
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 lt50Kb and can be easily ported
  to other JFFS2 versions

15
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.
JFFS2 file_ops.write()
Application requests to write data
6KB
4KB
Large chunks
Merge nodes
JFFS2 Write RAM buffer
1KB
2KB
4KB
1KB


JFFS2 flush RAM buffer
Sync()
16
Conclusion
Patches to provide Direct I/O in JFFS2 are
ready Significantly reduce RAM usage and open
time Easy applicable- Has restrictions on
large write chunks
17
Q A
Questions ?
Link http//sourceforge.net/mtd-modsmailto
alexey.korolev_at_intel.com