similar to: Proposal for DTrace probes for NFS v3 client

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

Hi, I am adding DTrace probes within NFS v3 client. In my current implementation, I use some tsd_*() functions and kmem_zalloc() function. These functions might be heavy and affect the performance. I want to call this function only when DTrace is running or the DTrace probes are enable. So is there a way to check DTrace is running or DTrace probe is enabled? Regards, Danhua

Hi, I have got an implementation of DTrace probes for NFS v3 client. Webrev of my change is at: http://cr.opensolaris.org/~danhua/webrev/ The provider and probes are described in attached proposal. Welcome comments! Regards, Danhua -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: proposal-nfsv3client.txt URL:

We recently had a strange NFS performance anomaly between a V880 running snv_124 and two NetApp filers. To investigate, a DTrace NFSv4 (and eventually NFSv3) client provider would been extremely helpful. Unfortunately, all I could find were a request for code review of a v3 client provider and another request for help developing a v4 provider. Nothing seems to have come from those initiatives,

I have added a specification of probes for the fibre channel COMSTAR port provider to the DTrace section of wikis.sun.com. The proposal may be found here: http://wikis.sun.com/display/DTrace/fibre+channel+Provider I welcome feedback regarding this proposal. Thanks, Sam

X.Org has adopted GNU autoconf as its build configuration mechanism, so when I integrated the dtrace probes, I checked to see if they should be built using this test, checking for the existence of a program named "dtrace" in the path: dnl Check for dtrace program (needed to build Xserver dtrace probes) AC_ARG_WITH(dtrace, AS_HELP_STRING([--with-dtrace=PATH], [Enable dtrace

Hi, I have mentioned before that we have added some sdt dtrace probes in SAX, our APL interpreter. Encouraged by Angelo and Jignesh, I have created a small document (5 pages) describing our experience with it, together with some problems we have encountered and some scripts we use for pretty-printing dtrace outputs. The said document can be found at

I am currently working on adding DTrace probes we have for Memcached 1.2.5 to the new binary protocol in 1.3 branch. The problem I am facing is that I should have had a new variable into the probe. When we added the probes, all memcached keys would be zeroterminated ascii strings, but in the binary protocol it may not be zero-terminated. So what do I do? According to

The earlier post with the Dtrace probes definition (sent on April 23) was only to solicit feedback from all prospective users of iSCSI DTrace probes. I will follow up shortly with an updated document requesting approval from the community. thanks Priya -------- Original Message -------- Subject: Dtrace provider for the COMSTAR iscsi Target Port Provider - Review Request Date: Thu, 23 Apr

I've integrated some DTrace [1] probes into R. Namely a probe which fires on fuction entry and return and one which fires before / after a garbage collection. Is there any interest in merging something like this into R-devel? If yes, I'd like to discuss which probes and what data would be useful / interesting from a developers standpoint. Greetings from Dortmund, Olaf Mersmann [1]

Author: ahl Repository: /hg/zfs-crypto/gate Revision: b1ab97f77b0ad2a4fe2a43d9c5aac7259840bb90 Log message: 6370454 dtrace should support USDT probes in static functions Files: update: usr/src/lib/libdtrace/common/dt_dof.c update: usr/src/lib/libdtrace/common/dt_link.c update: usr/src/lib/libdtrace/common/dt_provider.c update: usr/src/lib/libdtrace/common/dt_provider.h

Hi, As I''ve discussed before whenever we add USDT probes to a C++ function and call dtrace -l we get the mangled C++ name for the dtrace function, being listed :( Now the point of USDT probes is to abstract a higher level semantic construct for users to make use of. Surely it is not meant to be listing Unstable Interfaces (implementation details), such as the containing C++

Hi, I am profiling some workloads for the voluntary and involuntary context switches. I am interested in finding out the reasons causing these two types of context switches. As far as I understand, involuntary context switch happens on expiration of time slice or when a higher priority process comes in. While the voluntary switch generally happens when a process is waiting for I/O etc. So to

Hi, I am soliciting input from the ZFS engineers and/or ZFS users on an extension to "zfs list". Thanks in advance for your feedback. Quick Background: The pNFS project (http://opensolaris.org/os/project/nfsv41/) is adding a new DMU object set type which is used on the pNFS data server to store pNFS stripe DMU objects. A pNFS dataset gets created with the "zfs

Does anyone out there have any thoughts on the type of load common DTrace scripts would cause on a system if run 24x7? I know "common DTrace scripts" and their underlining probe calls a vague statement. So for the lack of a common and establish set of scripts in the OS, I''ll use the most popular right for my question...the DTraceToolkit from Brendan Gregg. Which by the

I would like to request approval of the the DTrace proposal for the COMSTAR iSCSI target port provider. I have updated the specification of the iscsi provider at http://wikis.sun.com/display/DTrace/iscsi+Provider. Your feedback is appreciated. thanks Priya -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: iscsit_dtrace_draftv8.txt URL:

Is there a limit on the number of user space probes that can be present at any time? I have compiled very many probes into our product, and can''t see all of them in "dtrace -l". it looks very much like I have all of them up to some point at which I''ve hit some hard limit. I can see a total of 8588 probes, I think 2 processes have all of the ones I expect (one has 1752

Hi All, I''ve got a problem when I have USDT probes in a static library and in the application code outside of the library. I build the static library containing some USDT probes, glomming everything together (ld -r) before creating the .a file to preserve the probe symbols. This all works fine. I build an application which also has some USDT probes. When I build the application which

Is there any way to get printf type functionality inside the kernel from dtrace probes. Basically I want to dump progress through flow in my device driver. Something like: DTRACE_PRINTF("Inside chip reset, mailboxes %x %x %x %x %x %x %x %x", mb1, mb2, .....); ... ... DTRACE_PRINTF("reset failed: reason %s", failure_reasons[err]); I may have several such probes and they may

I added a couple of static probes to Firefox to measure actual work done. I could have used a pid$target probe with a function name but work is done within an if statement, which is where I placed the static probes. I''m wondering about my use, though. Is the following significantly more efficient than pid$target::FunName:entry and return? I heard somewhere that $target does not