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

Re: JFFS2 endianness.

| In response to a private mail asking about the CPU time taken for such 
| byteswapping - essentially "since most flash is soldered down, is it worth 
| spending the CPU time to be portable?"....

I suspect the CPU time taken in byteswapping is going to be lost in the 
noise. Most of the time the CPU spends in JFFS2 is spent on the internal 
data structures in RAM, not processing the actual nodes from the flash.

We can benchmark it when I change it over - and if it does make a 
significant difference we can reconsider, but I don't think it will.

If you care about CPU time, there are plenty of places you could improve
JFFS2. Some of the list handling code is hopelessly na´ve - see how much of
a performance improvement we got when I applied a modicum of clue to
jffs2_remove_node_refs_from_ino_list(), for example.

I've recently had a report of bad performance on large files - take a look
at jffs2_read_inode_range() in read.c (in CVS):

        while(frag && frag->ofs + frag->size  <= offset) {
                D2(printk(KERN_DEBUG "skipping frag %d-%d; before the region we care about\n", frag->ofs, frag->ofs + frag->size));
                frag = frag->next;

It's going to churn away to itself for a _long_ time every time you read 
from near the end of a large file. Writing is similar.

We could probably get an instant win by keeping a 'halfway' pointer and
following the list from there if the node we're after is more than halfway 
through the list. I'm sure there are cleverer ways to do it too, if you are 
inclined to spend more than a few seconds pondering it. Suggestions in 
'diff -u' form please?

If you object to gratuitously wasting CPU time, consider also the
garbage-collect code which always decompresses a node and then recompresses
it to write it out again, even if it hasn't changed. :)


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