Date: Mon, 31 Jan 2005 08:56:44 +0100 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Mike Silbersack <silby@silby.com> Cc: Colin Percival <cperciva@FreeBSD.org> Subject: Re: tcp_isn_tick() / dummynet() callout madness ? Message-ID: <85971.1107158204@critter.freebsd.dk> In-Reply-To: Your message of "Mon, 31 Jan 2005 01:16:12 CST." <20050131011241.F64157@odysseus.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20050131011241.F64157@odysseus.silby.com>, Mike Silbersack writes: >That sounds neat, but I'm not sure it's a good idea. In the case of tcp >timers, there are multiple locks that are relevant, if I'm not mistaken. >I also have this feeling that when mutex contention really matters, under >serious load, it wouldn't be a good idea to indefinitely delay some >callouts. It is a good idea, if nothing else because it prevents us from stalling softclock on a mutex we cannot get (for a long time). >I'd propose a simpler approach: Two callout wheels. A "fast" callout >wheel for short callouts (like tcp_isn_tick), and a "slow" callout wheel, >for things like tcp timers which we should handle quickly, but won't care >too much if they get delayed. That is a worse idea because it almost doubles the overhead. >Scott, in your reply to this you mention the importance of callouts firing >on time - do we have such important callouts? Thinking from a system >resource perspective, are there callouts that free memory, garbage >collect, etc? It would make sense to give those priority over less >critical timers which might block. Yes, timeout firing precision is important. -- 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?85971.1107158204>