DragonflyBSD kernel clock improvements

Matthew Dillon dillon at apollo.backplane.com
Sat Jan 24 16:30:25 PST 2004

:Matthew Dillon <dillon at apollo.backplane.com> writes:
:>     The problem with the timecounters is that they create incredible
:>     inconsistencies depending on which counter you use, various pieces of
:>     hardware, your hz frequency, and the phase of the moon.  The timecounter
:>     code is ridiculously complex and unnecessary junk and I will be ripping
:>     it all out soon.  Every last bit of it.
:The "if I don't understand it it must be bad" attitude is what gave
:the world Linux.  Perhaps you should be more open to the idea that if
:you don't understand it, it's probably very hard to get right, and
:ripping it all out will leave you with something that only works when
:you're trying to figure out why it doesn't.
:Dag-Erling Smørgrav - des at des.no

    Who said anything about not understanding it?  That's your own psychosis,
    don't try to put words in my mouth Dag, I understasnd the timecounter
    stuff all too well.  That's why I am ripping it out.

    What's replacing it is a fine-grained interrupt-based timing subsystem
    which is MP aware and MP safe, which allows any cpu to register any
    number of one-shot or periodic interrupt-class callbacks set for any
    time interval down to the resolution of the system clock (- overhead).

    This means, amoung other things, that I don't have to deal with all those
    terrible IPI hacks you've got to distribute your clocks.  Instead the
    system clock interrupt distributes clock events to target cpus which
    registered them via our excellent, proven IPIQ mechanism.  No hacks,
    no messes, no fractional nanosecond or fractional 32 bit master 
    timekeeping monstrosities... it's gonna be clean all the way through
    and based on the system clock frequency, period end of story.

    It means that the scheduler tick and profiler tick can be coded
    independantly rather then the subdivision hacks that exist now.

    It means that the scheduler tick can be coded on a per-cpu basis,
    independant of hz, even.

    It means that nanosleep() will actually *WORK* properly, as will 
    timeval based timeouts such as those used in select().

    If means that we can code up per-cpu timer support and have it seemlessly
    integrate into the system, if that's the direction we want to go.

    It means a lot of things that, really, should have been done a long time
    ago in FBSD.

    It means that time conversions will occur at the edges instead of in
    the core.

    And you know something?  I don't give a flying fish head what you think
    anymore, but I will suggest that maybe it would be a good idea for you
    to stop defending bad code, suck in your pride, and start thinking about
    what 'next generation' is supposed to mean in the context of FreeBSD-5.

					Matthew Dillon 
					<dillon at backplane.com>

More information about the freebsd-current mailing list