From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Mon, 18 Nov 2013 09:15:33 -0500 To: 9fans@9fans.net Message-ID: In-Reply-To: <5aaee493e2190f3660f54100f1f99db8@hamnavoe.com> References: <5aaee493e2190f3660f54100f1f99db8@hamnavoe.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] arm & httpd Topicbox-Message-UUID: 8abab574-ead8-11e9-9d60-3106f5b1d025 On Mon Nov 18 06:46:22 EST 2013, 9fans@hamnavoe.com wrote: > > this is because wakeup() takes about 100-1000x as long as sleep(0) > > [Citation needed] since rendezvous has to do a bunch of locks and a context switch, whereas sleep(0) doesn't really have to do anything other than check anyhigher(), i thought this wouldn't need proof. here are some numbers. it turns out my lazy guess was too high, but the thing to remember is the time wasting and sleep(0) tricks work because rendezvous is quite slow. (the test results for semaphore locks vs tas locks were posted to the list, iirc, and tas locks generally come out on top. semaphores get worse as the number of processors increase.) the rendezvous numbers should be /4 so we have time per million rendezvous sleep0 kw 17.71 2.78 6.3 32c intel 1.01 0.14 7.2 4c amd .785 0.15 5.2 raw data # arm kirkwood; 1 processor kw; time 5.rpingpong; time 5.sleep0 4.86u 65.97s 70.84r 5.rpingpong 0.61u 2.17s 2.78r 5.sleep0 sooner; aux/cpuid -i Intel(R) Xeon(R) CPU E5-2470 0 @ 2.30GHz sooner; wc -l /dev/sysstat 32 /dev/sysstat sooner; time 6.rpingpong; time 6.sleep0 0.56u 1.27s 4.04r 6.rpingpong 0.05u 0.08s 0.14r 6.sleep0 ; aux/cpuid -i AMD Phenom(tm) II X4 965 Processor ; wc -l /dev/sysstat 4 /dev/sysstat ; time 6.rpingpong;time 6.sleep0 0.25u 1.29s 3.14r 6.rpingpong 0.06u 0.08s 0.15r 6.sleep0 - erik