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