[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [patch?] Re: Do ramdisk exec's map direct to buffer cache?



On Wed, 9 Aug 2000, David Woodhouse wrote:
> JFFS ought to be able to do XIP. You just need to make sure that the 
> executable data you want are page-aligned, and remain that way over 
> garbage-collection. Then munge the page tables to point at the relevant 
> pages directly in the flash chips.

Actually that is not strictly necessary:

> However, for obvious reasons XIP and compression are mutually exclusive. As 
> flash is more expensive than RAM, nobody really seems that interested in XIP 
> any more.

If you have an MMU, you can be more fancy than that. You can copy the
flash file contents into the page-cache on demand (just like we do today)
but if you're low on RAM, the OS will flush the pages as they're used. So
you don't really need XIP unless you can't even afford that couple of
pages necessary to run a program, or you lack an MMU (but then you can't 
do the page remapping trick anyway). That works with compression as
well..

OK it will be very slow if you just allow a few pages in the page-cache :)

> Seriously, if you were looking at XIP with 1MB RAM and 2MB flash, then I'd
> advise you to use compression instead, and swap the numbers to 2MB RAM and
> 1MB flash.

I agree that 2 ram 1 flash is better than 1 ram 2 flash, but with
compression and on-demand loading you can do 1 ram 1 flash maybe :) 

> (Actually, JFFS has memory usage problems which need to be addressed before
> we can really cut the RAM down that far. Being a log-structured filesystem,
> it keeps a permanent cache of data about each node on the media. This means
> it uses lots of RAM to cache info about inodes it's rarely going to use, and
> also it takes a long time to scan the flash on boot. The problem with
> dropping that cache and scanning on demand is that you may need to scan the
> _whole_ flash again every time you want to find an inode which you've
> previously dropped, which is _slow_.)

I would not say it's "lots of RAM".. ok it's obviously not scaleable, but
in absolute numbers for a moderately sized R/W filesystem part on an
embedded device, it's no problem. What's needed to make it really
scaleable is a checkpointing node (just like normal log-structured
filesystems).

Then you 1) keep metadata in the dentry cache instead, and 2) when dentrys
are flushed you go to the checkpoint on flash and only scan forward from
that to the logical end.

That speeds up the boot-phase also, but you still have to scan the flash
for the newest checkpoint. In practice in our products, the scan takes
only 0.5 seconds or so (for a 350kb R/W partition) without checkpointing.

-Bjorn