Prune obsolete raw_node_ref's from RAM

David Woodhouse dwmw2 at infradead.org
Wed Jul 14 03:08:51 EDT 2004


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...



-- 
dwmw2






More information about the linux-mtd mailing list