This is the mail archive of the mailing list for the systemtap project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Meeting minutes 20060727

Stone, Joshua I wrote:
On Thursday, August 03, 2006 12:43 PM, Jose R. Santos wrote:
> Frank Ch. Eigler wrote:
>> "Jose R. Santos" <> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]