tcp_isn_tick() / dummynet() callout madness ?

[Mike Silbersack]

On Mon, 31 Jan 2005, Poul-Henning Kamp wrote:

> In message <20050130191410.R62670 at odysseus.silby.com>, Mike Silbersack writes:
>
> One of the things I would like to see is for the callout api to gain
> a mutex pointer.
>
> If the pointer is not null, a mtx_trylock() is atempted, if it fails
> a taskq is used to execute this callout, otherwise the function is used
> as usual.
>
> -- 
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20

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.

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.

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.

Mike "Silby" Silbersack