initramfs optimization suggestions

[Frans Meulenbroeks]

[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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/