JFFS3 memory consumption

[Artem B. Bityuckiy]

On Wed, 26 Jan 2005, David Woodhouse wrote:

> On Wed, 2005-01-26 at 08:44 +0000, Artem B. Bityuckiy wrote:
> > K1 is decreased by the Ferenc Havasi's "summary" patch well. Would be
> > nice to decrease K2 either. Any Ideas how to do so?
> 
> For a start, we can increase the maximum node size. Limiting it to
> PAGE_SIZE means we have a larger number of nodes than we'd otherwise
> have. If we quadruple that, we'll probably end up with about a third as
> many nodes. 
I thought about to have several 4K chunks within one node. Thus we will 
keep reading fast but will have few nodes number. Didi you mean this?

> We can also look at true write-behind caching, if we're a _lot_ more
> careful about free space than we are now. To have data outstanding in
> the page cache, we need to be able to guarantee that we have enough free
> space to write it out, and we need to be able to write it out _without_
> allocating memory. That includes any memory which might be required for
> GC. Doing that would allow us to coalesce writes so we fill a page (or a
> full node size) more often.
Yes, agree, good idea!. This would be very good improvement. But I suppose 
this is the subject to distinct big discussion.

> Removing the __totlen field from the node ref is also a 25% improvement
> in its ram usage.
By the way, I have already done this at JFFS3.

> 
> Also, perhaps we could use _arrays_ of nodes instead of lists? That
> would allow us to drop one of the list pointers. Probably it's easiest
> to do this for the next_phys list -- make it an array in physical order.
> I'm not sure how workable that would be. You'd need to deal with
> reallocation, and it'd be hard to remove obsolete elements from the
> middle; you'd probably just have to leave them there.
Possibly. But IMHO this is not the best approach. How will we remove one 
node from list? Don't know.

A suppose we do not really need per-block node_ref list. We how have 
summaries and may read summary when the per-block list is needed. What do 
you think? See any potential problem?

> Perhaps we can use values other than pointers in our next_phys and
> next_in_ino lists. These objects are in slab caches, and are quite
> neatly laid out. We could find a way of referencing them which doesn't
> require a whole 32 bits (or 64 on some machines).
No, this is not always true. Imaging objects from different slabs. 
They are not "close" to each other. Moreover, we will need to take into account 
redzoning, which may be switched on or off. This is not JFFS3's deal, 
IMHO.


> Another idea which I don't think is workable but which someone may be
> able to get something from... can we reduce the 'offset' to something
> smaller than 32 bits? Make it an offset within the block instead of from
> the start of the medium? Probably hard because it's not that quick to
> _find_ the block given just a raw_node_ref*. But if we've already put
> all the nodes for a given block into an _array_ rather than a linked
> list then maybe...
Hmm, may be. But I suspect this need too much effords, but the result will 
not be very noticable.
 

--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.