dtrace discuss - Nov 2008 - Overhead evaluation of my nfsv3client probe implementation

Hi,

Thanks for the comment for my nfsv3client probe implementation! I have made
changes accordingly.
Webrev: http://cr.opensolaris.org/~danhua/webrev/

To reduce the overhead, I use a local variable to save XID, rather than 
alloc memory space with kmem_zalloc().

According to the overhead caused by tsd_get() and tsd_set(), I did an 
experiment to measure it.

In this experiment, I run a dtrace script to enable nfsv3client probes 
and measure time consumed by each nfsv3 operation and tsd_get() and 
tsd_get(). Then  I run some workloads in *filebench* to perform some 
file operations in a nfs mounted folder.  I use the ratio of time spent 
on sd_get()+tsd_get() to the time spent on the whole operation to 
evaluate the overhead.

The workload I selected are: randomrw, filemicro_rwrite, 
filemicro_rread,  randomread, randomwrite.

Summary of the result:

1.  for every operation, most of the distribution of ratio is less than 1%.
2.  for every operation, the average of the ratio is less than 1%.
3.  the time spent on tsd_get() and tsd_set() are very similar. so the 
ratio mostly depends on the time spend on operation.
4. In worst case, the ratio is very different from operation to operation.
    For operations like commit, the max ratio is only about 0.05%
    For operations like read the max ratio goes up to 10%
    For operations like write, the max ratio is even more than 40%

(Detail of the result in attachment)

To make improvement, I have following approaches. I would like to hear 
your feedback to them.

1. add an argument to rfscall() and rfs3call(), pass XID as an parameter
    pro: little performance overhead
    con: change all the code that calls  rfs3call() and rfscall(), even 
they are not related to nfs3 client

2.  insert  XID  into  some  argument of rfscall() and rfs3call()
    pro: little performance overhead
    con: change all the code that calls  rfs3call() and rfscall(), even 
they are not related to nfs3 client because rfscall() is not just for nfs3

3. move the dtrace probe declaration into rfscall(),
    pro: little performance overhead, each to catch XID, no need to 
change other parts
    con: lost information about current path and file

4. add a function to check if a nfsv3client probe is enabled.
    implementation: during nfsv3 client initialization, setup a table. 
Each probe has an entry which point to the code that will be modified 
when a nfsv3client probe is enabled.
    pro: no need to change on current code.
    con: platform dependent (It is different on x86 and sparc).

These are the approaches I am thinking about, welcome to comment them or 
suggest new one!

Regards,

Danhua


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: overhead-1.txt
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20081117/0ecc516a/attachment.txt>