Prune obsolete raw_node_ref's from RAM

[Øyvind Harboe]

On Wed, 2004-07-14 at 09:08, David Woodhouse wrote:
> On Wed, 2004-07-14 at 08:51 +0200, Øyvind Harboe wrote:
> > On Wed, 2004-07-14 at 08:41, David Woodhouse wrote:
> > > On Wed, 2004-07-14 at 08:26 +0200, Øyvind Harboe wrote:
> > > > Would all the performance problems go away if the lists were doubly
> > > > linked?
> > > 
> > > Well yes, but since the object of the exercise was to save memory,
> > > doubling the size of the objects in question doesn't really strike me as
> > > being the right way to approach the problem :)
> > 
> > The memory problem I ran into wasn't the size of the un-obsolete nodes,
> > but that they grew with the number of obsolete nodes.
> > 
> > I hate #if's in code as much as the next guy, but JFFS2 spans deeply
> > embedded systems to full-fledged PCs and it is only to be expected that
> > the different profiles have different needs.
> 
> Well, I'm more than happy to do 
> 	#define jffs2_prune_ref_lists(c, ref) do { } while (0)
> in the Linux code and let the implementation we're playing with live in
> eCos code alone. It would be nicer if it were generic though -- that's
> why I'm thinking about making it happen in a periodic pass, rather than
> doing it all on _every_ obsoletion. By doing it every single time, we
> maximise the amount of list-walking required. 
> 
> We could walk the next_in_ino list when we remove a given inode from the
> inode cache, dropping all obsolete nodes from it then in a single pass. 
> 
> And we could walk each eraseblock's list at some other time...

Hmmm... how about a configurable threshold(i.e. a maximum number
obsolete nodes) that triggers a "purge" at the end of
jffs2_mark_node_obsolete()?

A "purge" would be to loop through all the physical nodes and merge
those that can be merged.

For my purposes, I need to make sure that there is a predictable peak
usage of RAM. What precisely that peak usage is, is somewhat less
important.

-- 
Øyvind Harboe
http://www.zylin.com