New "timeout" api, to replace callout

Poul-Henning Kamp phk at phk.freebsd.dk
Sun Dec 2 08:04:02 PST 2007


In message <20071202075334.A11104 at xorpc.icir.org>, Luigi Rizzo writes:

>> I disagree, that case, should be "with a period between N and M,
>> at your choice".
>
>yes surely this is better. But since your initial interface only
>had one parameter for this i tried to stick with that.

Right now, I'm looking at the API to replace the current API.

New functionality can be added, as we find out what it should be
and how it should work.

>DEVICE_POLLING is one example. You poll (and do resource allocation)
>to avoid livelock generated by too many interrupts, but don't know
>in advance what's the correct polling rate so rely on the system administrator
>to set HZ appropriately.

Ahh, but isn't that the wrong way ?

Shouldn't the driver (or central polling) code dynamically adjust
the pollrate instead ?

>> >It wouldn't make sense to do poll-based event handling at the same
>> >rate on a 133MHz soekris or on a 3 GHz multicore cpu.
>> 
>> Hz is the same for those two, so today we poll at the same rate.
>
>but you'd bump HZ to 2k or 4k up on a modern CPU, and lower to 500
>on a soekris.

Nothing prevents dummynet or devicepolling from having a sysctl
to adjust the rate.

>> I'm applying Jim Gettys 3. rule from the X11 project:
>> 
>> 	3.The only thing worse than generalizing from one example
>> 	  is generalizing from no examples at all.
>
>for what matters that would apply to the ns/us/ms/s resolutions that
>you proposed. They may be intuitive units but it doesn't mean that they are
>the most appropriate ones.

There's trivially room for another 28 'unit' flags, but I don't want
to define them, until rule three above is satisfied.

with respect to ns/us/ms/s, there are plenty of places in device drivers
where datasheets specify timeout durations on those terms, and network
protocols add another dozen such well defined timeouts.

-- 
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.


More information about the freebsd-arch mailing list