Date: Thu, 10 Apr 2003 12:03:12 +0200 (CEST) From: Harti Brandt <brandt@fokus.fraunhofer.de> To: Mike Silbersack <silby@silby.com> Cc: John Polstra <jdp@polstra.com> Subject: Re: realtime problem Message-ID: <20030410113428.T664@beagle.fokus.fraunhofer.de> In-Reply-To: <20030409200025.K472@odysseus.silby.com> References: <20030409114957.GN83126@cicely9.cicely.de> <200304091900.h39J0igT063938@strings.polstra.com> <20030409200025.K472@odysseus.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 9 Apr 2003, Mike Silbersack wrote: MS> MS>On Wed, 9 Apr 2003, Harti Brandt wrote: MS> MS>> I first discovered this with the xl driver. Mike Silbersack commited a MS> MS>Hmmm, someone has summoned me? MS> MS>Here's the patch I started and stopped working on a few months back. As MS>you can see, it's small, but it reduces the amount of time spent in MS>mii_tick _greatly_. Most specifically, it doesn't waste time reading the MS>BMSR register twice, because even reading it twice doesn't mean that we MS>don't lose the race! In addition, it takes advantage of the fact that MS>since the link status bit is latch low, we do not need to proceed any MS>further if it's still high, thereby saving another few register accesses. MS> MS>Harti, you're more than welcome to investigate and see if those changes MS>reduce delay for you. :) With this patch I get the following timing: max=961655 count=13 mean=949228 xl_stats_update(c033efe0)+0 max=75353 count=13 mean=23229 schedcpu(c01689dc)+0 max=16885 count=12852 mean=1772 tc_ticktock(c016be00)+0 max=13126 count=26 mean=3517 pfslowtimo(c01887d4)+0 max=12105 count=13 mean=2908 comwakeup(c020bc0c)+0 max=11451 count=13 mean=3200 realitexpire(c016d42c)+0 max=8981 count=321 mean=1105 scrn_timer(c0212aa0)+0 max=8253 count=64 mean=1261 pffasttimo(c018882c)+0 max=6218 count=129 mean=2225 atkbd_timeout(c0205628)+0 max=5893 count=3 mean=5003 loadav(c0169814)+0 max=5117 count=144 mean=804 endtsleep(c016912c)+0 max=3416 count=13 mean=1017 if_slowtimo(c01abb48)+0 max=3362 count=2572 mean=452 nfs_timer(c01cc4e0)+0 max=3123 count=15 mean=2050 siobusycheck(c020a348)+0 max=1852 count=64 mean=398 logtimeout(c01771a4)+0 max=729 count=129 mean=233 roundrobin(c01689c0)+0 The max/mean values are in microseconds (measured using the TSC). For my use 960usec is still far too long. This is with if_xl.c:1.108, but there have not been any changes that affect this timing. What about the idea to use a kernel thread? harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030410113428.T664>