[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: What on Earth is JFFS2 GC doing?
> Hmm the comment is above the function " jffs2_remove_node_ref_from_ino
> _list", but the fn called in the profile is "jffs2_free_all_node_refs".
> Are they related?
jffs2_remove_ref_from_ino_list is inline and only ever called from
jffs2_free_all_node_refs. Cf. Chapter 4 of Documentation/CodingStyle
If you make it an out-of-line function you'll certainly find that it's
jffs2_remove_ref_from_ino_list which is taking the time. Read it and it'll
be immediately obvious why.
Each raw_node_ref is on two linked lists. One in physical order, one
per-inode. When we've erased a block we need to clean up the references to
the nodes which it used to contain. So we walk the physical list, and each
raw node ref on it has to be taken out of its per-inode list before it can
be freed. jffs2_remove_node_ref_from_ino_list() performs that function.
Unfortunately, it performs that function by walking all the way to the end
of the per-inode list and then back again to the node we've found, because
it has to find the previous node in that list. A doubly-linked list would
make that a trivial operation, at a cost of an extra 4 bytes of RAM for
every physical node on the medium.
There's one optimisation I'm tempted to try before doing that - at least we
don't have to walk any given per-inode list more than once, if we're being
sensible about it. Currently we go round it once for every node we want to
delete. If there's more than one node to delete from a given inode, that's
To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to email@example.com