On Mon, 31 Jan 2005, Poul-Henning Kamp wrote:
> In message <20050130191410.R62670@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
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