This is the mail archive of the
mailing list for the systemtap project.
Re: Meeting minutes 20060727
- From: "Jose R. Santos" <jrs at us dot ibm dot com>
- To: "Stone, Joshua I" <joshua dot i dot stone at intel dot com>
- Cc: "Frank Ch. Eigler" <fche at redhat dot com>, Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>, systemtap at sources dot redhat dot com, Mathieu Desnoyers <mathieu dot desnoyers at polymtl dot ca>
- Date: Thu, 03 Aug 2006 15:49:42 -0500
- Subject: Re: Meeting minutes 20060727
- Organization: IBM
- References: <C56DB814FAA30B418C75310AC4BB279D62E29D@scsmsx413.amr.corp.intel.com>
- Reply-to: jrs at us dot ibm dot com
Stone, Joshua I wrote:
On Thursday, August 03, 2006 12:43 PM, Jose R. Santos wrote:
> Frank Ch. Eigler wrote:
>> "Jose R. Santos" <email@example.com> writes:
>>> [...] One of the things we are currently working on is to have an
>>> alternative to gettimeofday. [...]
>> Josh Stone's kprobes-safe rendition gettimeofday has been in the
>> systemtap runtime for some time now. Is that not sufficient for
>> your purposes?
> The goal here is to improve performance. Gui Jian has timed
> _stp_gettimeofday_us() using LKET and it give a bigger overhead than
> do_gettimeofday(). By doing this in user space we can obtain better
> performance by avoiding disabling preemption or calling seqlock like
> _stp_gettimeofday does.
If you have suggestions for improving _stp_gettimeofday, I'm all ears.
I'm never of the mind that the existing code is the perfect solution.
But then, if you're doing something from userspace, I guess I don't
fully understand your usage model, or how that will be faster...
Is not that calculating something similar to gettimeofday in user space
will be faster that doing it with in the kernel. My point is that
printing raw cycles will have less of an impact than the calculations
needed for gettimeofday. Now, the algorithm used to do the calculations
in user space maybe 10 times slower that the one on the kernel, but at
that point I don't really care what the overhead of the algorithm is
because that overhead is not reflected at all on the trace data.
I'm not saying that the the performance of _stp_gettimeofday is
horrible, but since trace data needs to be processed in user space
anyway, we can reduce some of the overhead cause while gathering data by
offloading these calculations at a later time.