tcp_isn_tick() / dummynet() callout madness ?

[Poul-Henning Kamp]

In message <20050131011241.F64157 at 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 at 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.