: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>Received on Sat Jan 24 2004 - 15:30:25 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:39 UTC