lkml.org 
[lkml]   [2008]   [Aug]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    Subjectinitramfs optimization suggestions
    [Upfront apologies if this is the wrong place to post this to.Just
    give me a gentle redirect to the right place in that case.]

    I've been looking into improving the boot time of an embedded linux
    system (monta vista based).
    While doing so I detected that initramfs initialisation was one of the
    places where a lot of time was spent, so I looked into it in some more
    detail and came up with the following findings & suggestions.

    First proposal:
    ==========

    initramfs is build from a compressed cpio archive.
    Proposal is to introduce a build option to make the compression and
    decompression optional.
    Rationale 1: could be faster as it trades off I/O time (to read the
    image) against decompression time
    Rationale 2: for architectures that use compressed images (bzImage)
    actually we compress twice, which is not really efficient.

    I can implement this, but before spending time on it I would like to know if
    a) people consider this a good idea
    b) no one else already has doen this.


    Second proposal:
    ============

    after decompressing the cpio archive all files are made using
    sys_open/sys_write/sys_close and friends.
    This implies that a lot of system calls and data copying is done.
    It would be nice if that could be avoided.
    I'm not fully into all details of how ramfs is implemented, but would
    it be possible to e.g. dump all blocks of a tmp ram fs into a data
    structure (e.g.an array of blocks) while making the kernel, and while
    booting the kernel initialise the fs cache with these data? (I guess
    this would be around fs/dcache.c; I understand the data here is
    kmalloc-ed, but it might be possible to initialise the cache with
    pointers to that data structure; due to the nature of ramfs they won't
    be deallocated anyway I assume).
    Does this sound feasible? Hidden snags? Appreciate your
    opinion/feedback/suggestions.

    Best regards, Frans.

    PS: if anyone has a pointer to a place which explains in full detail
    how linux fs internally works (apart from the source :-) ) I
    appreciate a reference. FM


    \
     
     \ /
      Last update: 2008-08-05 09:45    [W:8.874 / U:0.036 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site