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

From Julian Elischer <julian@xxxxxxxxxxxx>, 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 @
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 @
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@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"


_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"
_______________________________________________
freebsd-performance@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "freebsd-performance-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Fine-grained locking for POSIX local sockets (UNIX domain sockets)
    ... is running on the same CPU. ... you should just read the TSC. ... cheap, synchronized, and accurate TSC time on SMP systems. ... patch and this time with 6 tests for each setting and generated graphs: ...
    (freebsd-current)
  • Re: Fine-grained locking for POSIX local sockets (UNIX domain sockets)
    ... 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. ... 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. ...
    (freebsd-current)
  • Re: Fine-grained locking for POSIX local sockets (UNIX domain sockets)
    ... 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. ... 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. ...
    (freebsd-performance)
  • RE: [patch 1/] timers: tsc using for cpu scheduling
    ... I should underline that patch deal with the alternative which timer to ... time as a measure of CPU work for scheduling is described in the Linux ... scheduling time measurement because TSC may miss 2-3 clocks during CPU ... * It is not recommended to use this function for other than scheduler ...
    (Linux-Kernel)
  • RE: [patch 1/] timers: tsc using for cpu scheduling
    ... > cpu to brother which wait mutex unlock and will do the same. ... I'm just asking if using the TSC ... I'm not a scheduler guy, so forgive my ignorance, but since the TSC may ... That's fine if its what you propose, I just didn't see it in your patch. ...
    (Linux-Kernel)