Uh, for starters, I'd like to point out that the appropriate response
to a message of the form `I think the following would be a good idea'
is rarely `have you done a month worth of research on this problem??'
That's what your reply looks like to me, and I find it somewhat
annoying.

That said...

1) I am rather familiar with it.  However, calling this merely
   `timeout() usage' is short-sighted.  The ultimate goal is to be
   able to do much more fine-grained scheduling.

   (E.g., rather than taking scheduler interrupts at 100Hz to do
   mostly make-work, we should know when the next forced task switch
   will be and schedule an event to occur at that time.  There are
   many other such examples.)

2) There are a lot of alternative data structures.  (And, FTR, I
   really don't need section references to Knuth!)

   It is not terribly realistic to expect all callers to preallocate
   memory.  E.g. if I want to allow user processes to set multiple
   timers, the changes to process data structures would quickly become
   an annoyance.  You'd end up with lots of hair anywhere you want
   potential flexibility.  I'm not interested in going that route.

   In addition, it doesn't buy you anything.  At any point where you'd
   be allocating memory for something that includes a callout
   structure (e.g. a device softc), you could equally well ask the
   callout system to reserve one or more callouts for you.  This would
   have several advantages, including a reduced TLB footprint and less
   overall memory usage (as there is no need for tree pointers in the
   heap structures; the only `wasted' space being the level map and
   slop at the end of the allocations).

   (It's worth noting that if the caller wants to be able to delete
   the timeout from the heap, it must get a handle back.  The form of
   that handle is quite flexible, however; it would probably be some
   integer combination of the level and index, as this information is
   needed to do the removal and would be annoying to derive.  Callers
   that don't need to do deletion can simply ignore the handle.)

Some of this has been discussed before, BTW.