Re: Meeting minutes 20060727

["Jose R. Santos" <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" <jrs@us.ibm.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. 

-JRS