a proposed callout API
Hans Petter Selasky
hselasky at c2i.net
Thu Nov 30 01:42:50 PST 2006
On Monday 13 November 2006 21:53, Poul-Henning Kamp wrote:
> A number of problems have been identified with our current callout
> code and I have been thinking about and discussed various aspects
> with people during the EuroBSDcon2007 conference.
>
> A lot of people are interested in this, so here is a quick sketch
> of what I'm thinking about:
>
>
> The Problems
> ------------
>
> 1. We need better resolution than a periodic "hz" clock can give us.
> Highspeed networking, gaming servers and other real-time apps want
> this.
>
> 2. We "pollute" our call-wheel with tons of callouts that we know are
> unlikely to happen.
>
> 3. We have many operations on the callout wheel because certain
> callouts gets rearmed for later in the future. (TCP keepalives).
>
> 4. We execute all callouts on one CPU only.
>
> 5. Most of the specified timeouts are bogus, because of the imprecision
> inheret in the current 1/hz method of scheduling them.
>
> and a number of other issues.
>
>
> The proposed API
> ----------------
>
> tick_t XXX_ns_tick(unsigned nsec, unsigned *low, unsigned *high);
> Caculate the tick value for a given timeout.
> Optionally return theoretical lower and upper limits to
> actual value,
>
> tick_t XXX_s_tick(unsigned seconds)
> Caculate the tick value for a given timeout.
>
> The point behind these two functions is that we do not want to
> incur a scaling operating at every arming of a callout. Very
> few callouts use varying timeouts (and for those, no avoidance
> is possible), but for the rest, precalculating the correct
> (opaque) number is a good optimization.
>
Hi,
I have some comments on the matter.
Is XXX_arm only an init routine? If not, it does not make sense that one is
allowed to pass a variable mutex argument. This will lead to some locking
problems I think. Also I am missing the CALLOUT_RETURNUNLOCKED flag.
> XXX_arm(struct xxx*, tick_t, func *, arg *, int flag, struct mtx *);
> Arm timer.
> Struct xxx must be zeroed before first call.
>
> If mtx pointer is non-NULL, acq mutex before calling.
This makes sense. Should also require this for rearm/disarm, but not drain.
>
> flags:
> XXX_REPEAT
> XXX_UNLIKELY
>
> Arm a callout with a number of optional behaviours specified.
>
> XXX_rearm(struct xxx*, tick_t)
> Rearm timer.
>
> XXX_disarm(struct xxx*)
> Unarm the timer.
>
> XXX_drain(struct xxx*)
> Drain the timer.
>
>
> The functions above will actually be wrappers for a more generic
> set of the same family, which also takes a pointer to a callout-group.
>
> This is so that we can have different groups of callouts, for
> instance one group for the/each netstack and one for the disk-I/O
> stuff etc.
Why can't you just rename and extend the existing
callout_init_mtx()/callout_reset()/callout_stop()/callout_drain() functions ?
Yours
--HPS
More information about the freebsd-arch
mailing list