From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <94720e19021f594c5f0007d2b975d14f@brasstown.quanstro.net> References: <94720e19021f594c5f0007d2b975d14f@brasstown.quanstro.net> Date: Tue, 8 Dec 2009 17:05:14 -0800 Message-ID: Subject: Re: [9fans] etherigbe.c using _xinc? From: Russ Cox To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Topicbox-Message-UUID: ad8dd192-ead5-11e9-9d60-3106f5b1d025 On Tue, Dec 8, 2009 at 4:32 PM, erik quanstrom wrot= e: >> but the former does two operations and the latter >> only one. =C2=A0your claim was that _xinc is slower >> than incref (=3D=3D lock(), x++, unlock()). =C2=A0but you are >> timing xinc+xdec against incref. > > sure. =C2=A0i was looking it as a kernel version of a > semaphore. no, your original claim was that incref/decref was faster than _xinc/_xdec. the numbers don't support that claim. > the reference > counting is a heavy price to pay on every network > block, when it is only used by ip/gre.c. has the network gotten fast enough that an extra bus transaction per block slows it down? it seems like gigabit ethernet would be around 100k packets per second, so the extra 50ns or so per packet would be 5ms per second in practice, which is significantly but hardly seems prohibitive. > before allocb/freeb > did 2 lock/unlocks. now it does 2 unlock/locks > + 2 xinc/xdec, and is, in the best case 31% slower. > and in the worst case 90% slower. i don't know how you get those numbers but anything even approaching that would mean that the kernel is spending all its time in igberballoc, at which point you probably have other things to fix. russ