Hi,
I made some optimizations on racache in nfsd in test10. The idea is to
replace with existing fixed length table for readahead cache in NFSD with a
hash table.
The old racache is essentially ineffective in dealing with large # of
files, and yet eats CPU cycles in scanning the table (even though the table
is small),
the hash table-based is much more effective and fast. I have generated the
patch for test10 and tested it.
(See attached file: nfshdiff)(See attached file: nfsdiff)
Ying
On Friday November 10, [email protected] wrote:
> Hi,
>
> I made some optimizations on racache in nfsd in test10. The idea is to
> replace with existing fixed length table for readahead cache in NFSD with a
> hash table.
> The old racache is essentially ineffective in dealing with large # of
> files, and yet eats CPU cycles in scanning the table (even though the table
> is small),
> the hash table-based is much more effective and fast. I have generated the
> patch for test10 and tested it.
>
> (See attached file: nfshdiff)(See attached file: nfsdiff)
>
>
> Ying
Thanks for this.
A couple of questions and comments:
1/ Do you have any stats showing what sort of speedup this gives -
I'm curious.
2/ Was there a particular reason that you didn't use the
include/linux/list.h
list structures for the hash and lru chains? If not, I suggest
that doing so would be a good idea. It should make the code
clearer and more in-keeping with other code in the kernel.
3/ It is easiest for (many of) us if you just include the patch
in-line in your email messages rather than as an attachment. You
can then be sure that EVERY mail reader can display it
effectively, and Linus has said a number of times that he doesn't
like attachments.
3a/ If you or your mailer insists on using attachments, please make
sure that the mime-type of the attachment is correct - text/plain,
not applications/x-unknown. Again, that makes it a lot easier to
read your patch.
4/ I doubt that this is significant enough to go in before 2.4.0-final now,
but it probably has a reasonable chance of getting in shortly
afterwards.
NeilBrown
knfsd maintainer.
1/ Do you have any stats showing what sort of speedup this gives -
I'm curious.
I don't have the exact timing stats to show the improvements, but I do have
some stats that I gathered when running SPEC SFS.
Basically with the default racache scheme which only keeps 80 entries in
the table (if I remember the # right), since SPEC SFS works on a lot of
files, I can see that shortly after the SPEC SFS test gets started, the
table is filled up, and nfsd_get_raparam() will never insert any other ra
values to the table, i.e., the racache hit ratio is always 0 for the SPEC
SFS runs, and yet each time when it's called, it scans the entire table
once, i.e., 80 table entries. On the other hand, when hash table is used,
on average, the old files can be removes and new entries can be added
dynamically, so the hit ratio improves and even if there isn't a hit, the
hash chain search is far more better than a table scan. On average, at most
a few list walk will suffice.
2/ Was there a particular reason that you didn't use the
include/linux/list.h
list structures for the hash and lru chains? If not, I suggest
that doing so would be a good idea. It should make the code
clearer and more in-keeping with other code in the kernel.
No there isn't. Oh, well, maybe there is... I used nfscache.c as the base
when I built racache, which didn't use list.h.
Having said that, I just did not try hard to make the kernel more
consistant.
3/ It is easiest for (many of) us if you just include the patch
in-line in your email messages rather than as an attachment. You
can then be sure that EVERY mail reader can display it
effectively, and Linus has said a number of times that he doesn't
like attachments.
3a/ If you or your mailer insists on using attachments, please make
sure that the mime-type of the attachment is correct - text/plain,
not applications/x-unknown. Again, that makes it a lot easier to
read your patch.
No problem with this. I will do that for the future patches.
4/ I doubt that this is significant enough to go in before 2.4.0-final
now,
but it probably has a reasonable chance of getting in shortly
afterwards.
I really hope that this can go into 2.4, since the changes are really
straight-forward and I've been testing and running this under a wide range
of situations for a couple months in my own patched kernels. I probably
should have sent it a bit earlier. Oh, well.
NeilBrown
knfsd maintainer.