> On Tue, Aug 10, 1999 at 11:46:56AM -0400, Alexander Viro <viro@math.psu.edu> wrote:
> > Beautiful. Just to clarify: proposed patch drops the cached offset in the
> > rename(), so it's OK in that area.
>
> Thank you for the applaude. Actually, it was my very first result of
> Linux kernel hack...
>
> > 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
>
> Oops! I didn't aware of that. The reason I changed ext2_match() was
> for my news server, where almost all files have same leading characters,
> as:
> news:~/spool/articles/control/cancel$ ls -1 | tail -10
> 32942461
> 32942462
> 32942463
> 32942464
> 32942465
> 32942466
> 32942467
> 32942468
> 32942469
> 32942470
>
> Therefore, for news servers, checking the last character first should
> be a great win. Anyway, please correct my error and clean up my patch
> as well.
Checking the last character is not that big win. For 8-byte names the very
first access will suck both into the cache. Ditto for your variant. I'm
not sure that cost of taken branch will not outweight the benefit from
doing less comaprisons. Actually memcmp is overkill here - we don't care
*who* is greater, just whether they are different or not.
> > 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 will certainly appreciate a lot if you do that. Your caching should
> be more effective for the general puropse users.
OK, I'll finish the tesing and post the merged patch.
Cheers,
Al
-
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/