Re: Fine-grained locking for POSIX local sockets (UNIX domain sockets)

>From Julian Elischer <julian_at_elischer.org>, Tue, May 09, 2006 at 10:35:06AM -0700:
> Sven Petai wrote:
> 
> are there any patches that take the gettimeofday() calls and replace 
> them with something that is cheap
> such as only doing every 10th one and just returning the last value ++ 1 
> uSec for the other ones..
Better yet, just realize that during any given scheduler quantum the process
is running on the same CPU.  Therefore, you should just read the TSC.  

For that matter, if libc would just remember an accurate synchronized 
timestamp and TSC pair on a per CPU basis, it should be trivial to get 
cheap, synchronized, and accurate TSC time on SMP systems.  TSC drift 
isn't horrible--and best of all if the process drifts from CPU to CPU 
libc will have a decent chance at doing incremental calibrations.  Simply
giving libc easy access to a counter of scheduler ticks can be used to 
ensure this process delivers monotonic time.

Let me formalize this a bit, you have a noisy, but cheap time source: 
the TSC always available provided you compute your deltas a per cpu basis.  
You have another low resolution, low noise, but cheap time source: the 
count of scheduler ticks.  Rather than coding an ad hoc algorithm,
this information should be fed into a kalman filter.

There are some lingering details: you need to invalidate the
TSC when the processor speed changes: but this is controlled
by powerd no?  Second, if you can manage to throttle the CPU
it suggests that you can also manage to pay higher time
query costs and force clock_gettime calls.

It seems obvious that the mechanism should adapt to the
workload.

                                 Paul

> 
> a ktrace of Mysql shows a LOT of gettimeofday() calls.
> 
> 
> >On Tuesday 09 May 2006 03:42, Kris Kennaway wrote:
> > 
> >
> >>On Tue, May 09, 2006 at 03:34:59AM +0300, Sven Petai wrote:
> >>   
> >>
> >>>>Hmm, with this patch mysql 4.1 seems to crash at startup.  I haven't
> >>>>yet had time to investigate.  Is anyone else seeing this?
> >>>>       
> >>>>
> >>>Seems to run fine here with 4.1.18 on amd64, but doesn't seem to make
> >>>much difference though.
> >>>
> >>>I ran the tests again on the 8 core machine with and without rwatsons
> >>>patch and this time with 6 tests for each setting and generated graphs:
> >>>http://bsd.ee/~hadara/debug/mysql4/stats.html
> >>>
> >>>thr + select smack dynamics with the patch really do look quite
> >>>interesting
> >>>
> >>>PS
> >>>I'm currently running testround with rwatsons patch +
> >>>http://people.freebsd.org/~csjp/kern_descrip.c.1145074052.diff  + mysqld
> >>>change davidxu suggested.
> >>>Are there any other patches out there that I should try ?
> >>>     
> >>>
> >>Sorry, I meant
> >>http://people.freebsd.org/~csjp/sys.mpsafe.fileops.1145896495.diff
> >>instead of that patch.  Also try turning down HZ to 100, and changing
> >>the wakeup()s to wakeup_one() in sys/filedesc.h.
> >>   
> >>
> >
> >I preformed additional tests with the settings you suggested,
> >updated graphs are available _at_
> >http://bsd.ee/~hadara/debug/mysql4/stats.html
> >
> >* with rwatsons patch + mysqld change suggested by davidxu +
> >  http://people.freebsd.org/~csjp/sys.mpsafe.fileops.1145896495.diff
> > there doesnt seem to be much difference, but in general things seem to be 
> >couple of percent better
> > mutex profiles for this configuration are available _at_
> > with 10 smack threads: 
> >http://bsd.ee/~hadara/debug/mysql4/freebsd_cur_ps2/mutex_freebsd_cur2_p2-select_10_10000.txt
> > with 100 smack threads: 
> >http://bsd.ee/~hadara/debug/mysql4/freebsd_cur_ps2/mutex_freebsd_cur_p2-select_100_1000.txt
> >
> >* second run was with same patches, but HZ set to 100
> > this helps performance a lot but creates large fluxuations in select 
> > results with >20 threads + thr, sometimes difference between 2 runs with 
> >same settings was 10000+ q/s
> >
> >I'm currently still testing wakeup() -> wakeup_one() suggestion.
> >
> >In addition I did full testrun on linux to see how much this hardware
> >is really capable of... graphs for that are available on the stats page 
> >too.
> >_______________________________________________
> >freebsd-current_at_freebsd.org mailing list
> >http://lists.freebsd.org/mailman/listinfo/freebsd-current
> >To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
> > 
> >
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"