> On Nov 13, 2015, at 2:47 PM, Arnaldo Carvalho de Melo <a...@kernel.org> wrote: > > Em Fri, Nov 13, 2015 at 05:01:57PM +0000, Kornievskaia, Olga escreveu: >>> On Nov 12, 2015, at 6:34 PM, Arnaldo Carvalho de Melo <a...@kernel.org> >>> wrote: >>> There is also: >>> >>> 11.033 ( ): nfs:nfs_fsync_enter:fileid=00:26:2360376 >>> fhandle=0xfd52be06 version=6216410999163535246 ) >>> 15.535 ( ): nfs:nfs_fsync_exit:error=0 fileid=00:26:2360376 >>> fhandle=0xfd52be06 type=8 (REG) version=6216410999169535149 size=1576 >>> cache_validity=25 (INVALID_ATTR|INVALID_ACCESS|INVALID_ACL) nfs_flags=4 ()) >>> >>> Well, you also can just get these and do some scripting, no, in this case: >>> >>> 15.535 - 11.033 = 4.502ms >>> >>> for that nfs_fsync :-) > >> David and Arnaldo thank you your replies. I can see that to acquire >> the timings for non-syscall events requires scripting. Would I be >> missing something by not using “perf” and instead doing scripting on >> the output that I get from the trace_pipe? I guess instead of the > > Both will present you with the timestamp and parameters for the enabled > tracepoints, so I think that at this state, yes, you will not get > anything better from perf than what you'll get from ftrace via debugfs.
Actually one thing that came to mind that I would like to clarification about. I know that tracepoints are “lossy” and that if the “reader” of the pipe is not consuming fast enough and the ring buffers get full then tracepoint information gets dropped and pipe logs that it lost events. When I run “perf record”, is it also recording every tracepoint or is it sampling (which I don’t exactly understand but I think of it as it just periodically captures the tracepoint info which basically means it’s losing them intentionally)? > But this comes from time to time, the logic used for > raw_syscalls:sys_enter -> raw_syscalls:sys_exit, using some set of keys > to match one to the other should be extended to be used with non-syscall > events, such as the ones you mention here. > > i.e. whereas raw_syscalls:sys_exit has a "ret" variable to tell the > result of the sys_enter+sys_exit operation, nfs_fsync_exit has "error", > I guess, for the same purpose :) > I don’t exactly follow what you are suggesting here. Are you saying I should look at the perf code that does parsing for raw sys calls and modify and use it for nfs tracepoints?
