Date: Tue, 28 Nov 2006 23:10:10 -0200 From: Ricardo Nabinger Sanchez <rnsanchez@wait4.org> To: John Baldwin <jhb@freebsd.org> Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, freebsd-arch@freebsd.org Subject: Re: a proposed callout API Message-ID: <20061128231010.cbdc4e1d.rnsanchez@wait4.org> In-Reply-To: <200611281631.19224.jhb@freebsd.org> References: <7105.1163451221@critter.freebsd.dk> <200611281631.19224.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 28 Nov 2006 16:31:18 -0500
John Baldwin <jhb@freebsd.org> wrote:
> I had intended on using microseconds
> with a negative value indicating a relative timeout (so an 'uptime'
> timeout, i.e. trigger X us from now) and a positive value indicating an
> absolute timeout (time_t-ish, and subject to ntp changes).
Just some devil's advocate thoughts...
What are the advantages of encoding some semantic in one or two bits of the
argument, instead of passing another word with flags? The obvious is more
one word on stack per call, but how many words will have the code to deal
with those encoded semantic bits? I can see 2 feasible cenarios:
1- the critical path deals with a single word, but can possibly have more
branches and/or operations due to additional manipulation needed (extract the
semantic bits and act on them)
2- two words must be popped, so there's the chance of a complete cache-miss
penalty, which turns out to be some hundred cycles in every architecture.
Also, limiting the resolution to microsecond may leave the kernel in a short
blanket situation, considering the future trends (we're almost in the
picosecond processor era, although even nanoseconds are used very much,
being microseconds the "right"[1] choice).
Comments?
:)
[1] as of 2006.
--
Ricardo Nabinger Sanchez <rnsanchez@{gmail.com,wait4.org}>
Powered by FreeBSD
"Left to themselves, things tend to go from bad to worse."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061128231010.cbdc4e1d.rnsanchez>