In message <[EMAIL PROTECTED]>, Seigo Tanim
ura writes:
>Poul-Henning> I'm a bit worried about the amount of work done in the
>Poul-Henning> cache_purgeleafdirs(), considering how often it is called,
>
>Poul-Henning> Do you have measured the performance impact of this to be an
>Poul-Henning> insignificant overhead ?
>
>No precise results right now, mainly because I cannot find a benchmark
>to measure the performance of name lookup going down to a deep
>directory depth.
Have you done any "trivial" checks, like timing "make world" and such ?
>It has been confirmed, though, that the hit ratio of name lookup is
>around 96-98% for a box serving cvsup both with and without my patch
>(observed by systat(1)). Here are the details of the name lookup on
>that box:
Ohh, sure, I don't expect this to have a big impact on the hit rate,
If I thought it would have I would have protested :-)
>For a more precise investigation, we have to measure the actial time
>taken for a lookup operation, in which case I may have to write a
>benchmark for it and test in single-user mode.
I would be satisfied with a "sanity-check", for instance running
a "cvs co src ; cd src ; make buildworld ; cd release ; make release"
with and without, just to see that it doesn't have a significant
negative impact.
>It is interesting that the hit ratio of directory lookup is up to only
>1% at most, even without my patch. Why is it like that?
Uhm, which cache is this ? The one reported in "vmstat -vm" ?
That is entirely different from the vfs-namecache, I think it is
a per process one-slot directory cache. I have never studied it's
performance, but I belive a good case was made for it in the 4.[34]
BSD books.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
