Date: Tue, 01 Apr 2003 19:57:17 +0200 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Mike Silbersack <silby@silby.com> Cc: hackers@freebsd.org Subject: Re: "Expensive timeout(9) function..." Message-ID: <57215.1049219837@critter.freebsd.dk> In-Reply-To: Your message of "Tue, 01 Apr 2003 10:50:22 MDT." <20030401104630.T1612@odysseus.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20030401104630.T1612@odysseus.silby.com>, Mike Silbersack writes: >Yeah, I suppose limiting it to one mii_tick routine per second would help >somewhat... but it's still a bad situation. I wasn't advocating slowing it down that much, merely trying to run it sequentially out of timeout()'s hair. >Actually, we could improve it quite a bit if someone adds NANODELAY() >(hint, hint...) Couldn't we have a first-run nanodelay that just used >nanotime to do the counting for it? It should probably be called either nanosleep() or nanospin(). It is not a trivial task to do it. Writing the short end calibration code to be sufficiently robust and precise will take some time and a lot of experiments. There used to be a crumbled note with this somewhere in my stack of TODO items, but by now I suspect that it is ironed perfectly flat from the weight of all the stuff on top of it. But to add to my knowledge-base: What length of delays are you looking for ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?57215.1049219837>