> It looks like that ext2_find_entry() is one of the most frequently
> referenced functions and affects the system performance.
> Therefore, I browsed the source code and found a little spot, i.e.,
> When sys_unlink() does directory look up, it calls ext2_find_entry()
> if the target is not dcached. Getting the dentry, it checks the permission,
> and calls ext2_unlink(). However, the function ext2_unlink() calls
> ext2_find_entry() once again.
>
> Because the target is linearly searched, it is not effective to
> searching the same file from the start of the directory.
> If the "offset" of the "de" is remembered in the dentry struct,
> the next lookup can directly jump to the right block and right offset.
Beautiful. Just to clarify: proposed patch drops the cached offset in the
rename(), so it's OK in that area.
I have a couple of small fixes (e.g. foo[++bar]==baz[bar] is *not* a valid
C - order of evaluation is not guaranteed here), but the thing looks
really nice. Would you mind if I'll merge it with another kind of lookup
caching (if the directory didn't change since the last real lookup - start
searching from that position; it helps if we are going to do a sequence of
->lookup() after the readdir(), e.g. in any shell globbing, etc.)?
I've tested this thing on disposable^Wnon-critical filesystem (vfat) and
it works fine.
> Fortunately, there is a good field in the dentry, i.e., d_fsdata.
> It is initialized to NULL whenever the dentry is newly allocated.
> However, the current ext2 code never uses this field. Therefore
> we can save the "modified offset" there. We save the offset in a
> modified form to distinguish offset 0 and uninitialized offset NULL.
>
> Due to this change, synopsys of ext2_find_entry() and ext2_add_entry()
> are changed to use dentry directly. Also, a new function ext2_has_entry()
> is added.
[snip]
Cheers,
Al
-- Two of my imaginary friends reproduced once ... with negative results. Ben <float@interport.net> in ASR
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/