I have posted this before, but have extended the patch into a few more functions. The intent of the code is as before -- to improve JFFS2 lookups by not locking i_mutex for long periods when files are not in cache. For our embedded environment, we see a *five second* improvement in boot time. This patch is an attempt to improve the speed of JFFS2 at startup. Our particular problem is that we have a 30MB file on NOR flash which takes about five seconds to read and test the data CRCs. During this time access to other files in the same directory is blocked, due to parent->d_inode->i_mutex being locked. This patch solves this problem by adding a 'pre-lookup' call down to JFFS2, which can be called without this mutex held. When the actual lookup is performed, the results are in JFFS2's cache, and the dentry can be filled in quickly. However, given that I do not have experience at Linux filesystem code, I can't be sure that this is a correct solution, or that there isn't a better way of achieving what I'm trying to do. I feel there must be a way to do this without creating a new VFS function call. I suspect other filesystems could benefit from this too, as a lot of them call the same d_splice_alias() function to fill in the dentry. JFFS2 already seems to have all the lower-level locks that are needed for this to work; I don't know if that's true in other filesystems which could be relying on the directory's i_mutex being locked. Because JFFS2 needs to walk the entire file, there are big gains to be made here; other filesystems may gain little to nothing. I'm not expecting that this patch will get applied as-is, but please let me know if there is any merit to it, whether it should work, and what still needs to be done to if this is to be made part of the kernel. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
