Date: Mon, 16 Sep 2002 21:26:41 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Josef Karthauser <joe@FreeBSD.org>, "David O'Brien" <obrien@FreeBSD.org>, <cvs-committers@FreeBSD.org>, <cvs-all@FreeBSD.org> Subject: Re: cvs commit: src/sys/kern kern_timeout.c Message-ID: <20020916205714.H6839-100000@gamplex.bde.org> In-Reply-To: <13645.1032171121@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 16 Sep 2002, Poul-Henning Kamp wrote:
> In message <20020916195344.S6593-100000@gamplex.bde.org>, Bruce Evans writes:
> >fxp_tick() almost always causes one under load,
> >with an average of about 2 msec and a maximum of about 8 msec.
>
> I have seen other ${netcard}_tick() do the same. I wonder if the
I think think this is because they all call mii_tick() and mii_tick()
os the problem.
> 1 second timers in network drivers should be moved from timeout(9)
> to a kernel thread doing just that: polling net drivers 1/sec.
I think that would just increase overheads. The thread would cause
the same problem if it locked everything using Giant, and the timeout
can avoid these problems by not locking everything using Giant.
> >8 msec
> >is a huge bite out of the 10 msec between softclock for the default
> >HZ, and huger for larger HZ. softclock() expects to run multiple
> >timeout routines and shouldn't take more than 1% of the CPU(s) altogether,
> >but 8 msec per second is already 0.8% of 1 CPU for just 1 device.
>
> But couldn't some of this be due to evil DELAY() or locking in the
> in the timeout routine ? In that case it's only the duration, not
> the CPU usage which is .8% ?
DELAY() affects mainly the duration, and global (Giant only?) locking of
the timeout routine then makes large durations bad. DELAY() only locks
for each set of 3 bus accesses. fxp_miibus_readreg() uses evil DELAY(10)'s,
bu the cause of the large duration may be just that reading the register
really does take a long time -- the loop in fxp_miibus_readreg() takes
100 msec to time out and uses DELAY(10) mainly to implement the timeout.
> >I think most of the time is spent
> >in mii_tick(), and the overhead is not much larger than in RELENG_4.
>
> Yes, I've identified mii_tick() as well. Wild Bill Ethernet some
> time ago pointed out the the parallel issue that MII's should be
> run interrupt driven if at all possible to not steal bandwidth from
> the actual data.
Maybe reading the MII register takes a long time if and only if data is
being transferred. I've noticed that even reading the i8254 registers in
DELAY() takes 50 times as long as normal at certain times when fxp is
active (not usually, but most often for another DELAY() call from fxp,
one associated with starting (continuing?) transfers IIRC). So DELAY()
can take 170 usec longer than normal. This doesn't account for things
taking 8 msec unless there are a lot of DELAY() calls and they all take
much longer than normal.
> I agree that the prints are annoying, but right now I think they provide
> primary quality data, so I'd rather not take them behind an option yet.
They are already behind DIAGNOSTIC, so most people don't see them :-). I
temporarily enabled them by changing the ifdef.
Bruce
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020916205714.H6839-100000>