testing tree now ported/automaked and committed
Dear all: Yesterday I committed an adaptation of the testing tree to the autoconf/automake build system. Most tests now run on FreeBSD, and often report success. Here's a quick summary: OK: dispatch_api dispatch_apply dispatch_c99 * But that is not the point of this test dispatch_debug dispatch_group dispatch_pingpong dispatch_read dispatch_sema dispatch_timer_bit31 Mixed success: dispatch_after * Occasionally one or two fail dispatch_drift * Jitter fails, drift passes dispatch_starfish * Latency requirements not always met Pass, but no 'leaks' testing on non-Mac OS X: dispatch_cascade dispatch_readsync dispatch_timer_bit63 Failure: dispatch_priority * Blocks complete but fails precedence test Doesn't yet run on FreeBSD: dispatch_cffd * No Core Foundation on FreeBSD dispatch_cpp * No working C++ compiler with blocks off Mac OS X dispatch_timer_set_time * Requires legacy API I've left the original Darwin Makefile as Makefile.darwin, as it contains better runtime packaging and summarization, as well as knowing about lipo on Mac OS X. Some of this packaging should make it into the portable makefiles in the future. I plan to spend time investigating dispatch_priority today. Poor latency/jitter in some tests may be a result of my using a VM for testing, which I'll also investigate, but could also be a property of timer resolution, an off-by-one error in how wakeups are calculated (perhaps by the POSIX semaphore/kqueue code on FreeBSD?) but we'll see. I also ommitted some fixes to the POSIX semaphore code in libdispatch; I had some of the timeout calculation and handling wrong. One important semantic difference between Mach and POSIX semaphores is that their timed wait primitives take different time scales: Mach accepts a relative timeout, and POSIX and absolute timeout. There are arguments for/against both approaches, but I was pondering adding a non-portable POSIX semaphore extension to FreeBSD supporting relative timeouts to avoid additional clock reads to convert between the two bases. Robert N M Watson Computer Laboratory University of Cambridge
On 11/05/2009 10:18 AM, Robert Watson wrote:
I plan to spend time investigating dispatch_priority today.
FWIW, my testing showed the same problem with this test.
There are arguments for/against both approaches, but I was pondering adding a non-portable POSIX semaphore extension to FreeBSD supporting relative timeouts to avoid additional clock reads to convert between the two bases.
Computing relative timeouts from absolute timeouts is problematic because you never know if the process can be scheduled between the computation of the delay and the actual invocation of the wait. Computing absolute timeouts from relative timeouts, instead, never has this problem. Since time-fetching syscalls usually have a fastpath on modern OSes, it would be nice if libdispatch provided a way to specify an absolute timeout. Paolo
On Thu, 5 Nov 2009, Paolo Bonzini wrote:
There are arguments for/against both approaches, but I was pondering adding a non-portable POSIX semaphore extension to FreeBSD supporting relative timeouts to avoid additional clock reads to convert between the two bases.
Computing relative timeouts from absolute timeouts is problematic because you never know if the process can be scheduled between the computation of the delay and the actual invocation of the wait. Computing absolute timeouts from relative timeouts, instead, never has this problem.
Since time-fetching syscalls usually have a fastpath on modern OSes, it would be nice if libdispatch provided a way to specify an absolute timeout.
The libdispatch API and time representation seem to get this fairly right -- dispatch_time_t is able to internally represent the difference between a relative time and an absolute time. Robert N M Watson Computer Laboratory University of Cambridge
On Nov 5, 2009, at 1:18 AM, Robert Watson wrote:
Failure: dispatch_priority * Blocks complete but fails precedence test
Part (or all) of your problem might be not feeding the test enough work. If your machine is powerful enough, all of the work will get to run as soon as its ready and priority will never come into play. So try increasing the amount of work you give the test. -Bill
On Thu, 5 Nov 2009, William Siegrist wrote:
On Nov 5, 2009, at 1:18 AM, Robert Watson wrote:
Failure: dispatch_priority * Blocks complete but fails precedence test
Part (or all) of your problem might be not feeding the test enough work. If your machine is powerful enough, all of the work will get to run as soon as its ready and priority will never come into play. So try increasing the amount of work you give the test.
I wondered this, but when I increased the work by an order of magnitude, the same issue occurred: ================================================== [TEST] Dispatch Priority [PID] 9828 ================================================== LOW: 68 ******************************************* DEFAULT: 59 ************************************* HIGH: 65 ***************************************** Actual: 192 Expected: 192 [PASS] blocks completed Actual: 68 Expected: <65 [FAIL] high priority precedence (dispatch_priority.c:86) dispatch_priority.c:86 So it looks like they're being scheduled moderately fairly. A bit of grepping, but perhaps not entirely mature, search of the libdispatch code suggests that GCD priorities are not propagated to kernel thread priorities unless pthread work queues are used? Robert N M Watson Computer Laboratory University of Cambridge
participants (3)
-
Paolo Bonzini
-
Robert Watson
-
William Siegrist