realtime problem

[Harti Brandt]

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 at fokus.fraunhofer.de, harti at freebsd.org