[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: What on Earth is JFFS2 GC doing?




vipin.malik@xxxxxxx.com said:
>  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 
silly.

--
dwmw2



To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo@xxxxxxx.com