[lkml]   [2006]   [May]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subject[RFC] Advanced XIP File System
    I will be submitting a new filesystem for inclusion into the kernel as
    soon as it is ready. (It mounts but doesn't like doing much else
    right now.) I would like to get feedback now to mold the development
    as we go along. Please comment on the technical approaches and other
    inherent qualities or lack thereof. Let me know of any serious
    obstacles to inclusion in the mainline. We will Lindent it and clean
    it up quite a bit before really submitting.

    You may find it at its very boring sourceforge site Browse the source at
    Or get the tarball at

    What is it?:
    - AXFS for Advanced XIP File System.
    - Intended to be a root filesystem for embedded systems
    - Readonly
    - Uses addressable memory such as NOR flash instead of a block device
    - Borrows much from CRAMFS with Linear XIP patches
    - Allows XIP* of individual pages instead of just individual files
    - Uses filemap_xip.c where possible

    * By XIP, eXecute In Place, we mean that when a file is mmap'd() the
    pages are mapped directly to where they are stored in non volatile
    storage, rather than copied to RAM in the page cache and mapped from

    Why a new filesystem?
    - XIP of kernel is mainline, but not XIP of applications. This
    enables application XIP
    - Cramfs linear XIP patches not suitable for submission and lack some
    features of AXFS
    - Design allows for tighter packing of data and higher performance
    than XIP cramfs

    (Warning - Long explaination of why XIP support is important follows.
    Please read before flaming XIP.)

    I've heard people say, "XIP is stupid. Why on earth would I use
    expensive slow flash instead of cheap fast RAM?" Let me try explain
    why it can be smart and why it is actually done in practice. In fact
    many of the mobile handsets that run Linux use XIP CRAMFS today. If I
    take which is about 2MiB and throw it in JFFS2, it
    compresses to about 1MiB in flash. If I store as an XIP
    file (uncompressed) in XIP CRAMFS or AXFS it takes up 2MiB of flash.
    That is 1MiB extra flash for XIP. But the JFFS2 version would need
    2MiB of RAM to store that library when used while the XIP system uses
    0MiB. That means XIP uses +1MiB of flash and -2MiB of RAM for So for any extra flash used for XIP, it can save twice
    that amount of RAM. The end result can be lower cost systems on the
    small end. The secret is to choose what to make XIP and what to
    compress on flash.

    XIP can also increase performance. Processor caches make the slower
    read speed, compared to RAM, of a NOR type flash often used for XIP
    not important. However when an application 'bar' gets started and the
    code is mmap()'ed into the process the XIP system creates page table
    entries pointing to a physical address for all the code the process
    needs. Without XIP, as I understand it, basically empty page tables
    are created. As code is executed the system page faults and code is
    fetched from the filesystem, for example JFFS2, in a rather long
    process of copying to RAM, decompressing, and transfering to
    userspace. And of course this happens, interrupting execution of
    'bar', every time you access a new page of code. To misquote Linus
    "bow down before me, you scum" Torvalds, "That cost is _bigger_ than
    the cost of just copying the page in the first place." Code that is
    XIP takes that a step farther, it _never_ faults and _never_ gets

    To revisit the story lets say that the often used
    application 'bar' only calls one function in libfoo and therefore only
    pages in 1MiB of libfoo into RAM. Does this break the XIP argument?
    (+1MB Flash for -1MB RAM) Not with AXFS! A system designer could
    then choose to only XIP the specific pages within that are
    actually accessed. In that way the 2:1 ratio is retained. The AXFS
    effort will include some tools to help identify which pages do what,
    to help system designers optimize thier systems for memory usage.
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-05-02 23:55    [W:0.024 / U:8.364 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site