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.
:
:DES
:--
: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.
-Matt
Matthew Dillon
<dillon at backplane.com>
More information about the freebsd-current
mailing list