Thank you for replying, and sorry for delaying to reply for my network reason. I'm very happy that you all give me very useful advice :D
2010/3/31 Andriy Gapon <a...@icyb.net.ua>: > 1. Instead of firing clock (LAPIC timer) interrupt regularly with a frequency > derived from HZ, the interrupt is scheduled to fire (in one-shot mode) at the > time > of the soonest scheduled callout. > 2. The code also makes sure to run hard/stat/prof-clocks if time since last > interrupt is greater than their respective periods in !dyntick mode. Yes, that's right. > Thus, it appears that in dyntick mode hard/stat/prof-clocks would run > irregularly. > I couldn't find any code that makes sure that the rest of the system handles > this > properly. Perhaps I missed it, or is it still in progress/plans? Yeah, this is in progress. Next step is to support to hard/stat/prof-clocks run irregularly. Now, I'm reading code to understand how they work correctly in dyntick mode. > Also, I am not sure if the code handles the case when a new 'soonest' callout > is > scheduled after we already decided when to fire the next LAPIC timer > interrupt. In current version, this case is going to be ignored ( do nothing ). This is bug, and I'll fix it. 2010/3/31 Roman Divacky <rdiva...@freebsd.org>: > I wonder - why don't we store the callouts in binary > tree so the searching for nearest callout is faster? Is it time to have another look at callout queue implementation for this work? Or another implementation is to make callout queue have the nearest tick value. This costs O(1). > > what is the average length of the callout queue? I'm going to monitor it. 2010/3/31 Artem Belevich <fbsdl...@src.cx>: > Are you doing anything to handle the case where the lapic timer is turned off > when a CPU enters C2 or C3? No. Hmm, this is very big problem. > The ideal approach in my mind would be to not use > the lapic timer at all when running in a deadline mode, but give each CPU a > dedicated HPET comparator. Alternatively, you could add some special handling > where CPU 0 never goes into C2 or C3 but sends IPIs to other CPUs in deep idle > states when necessary (you could also let CPU 0 fake statclock() for said > CPUs > as well perhaps). I see. In SMP environment, this seems to be very good. I'll try to implement next version by using HPET. 2010/3/31 Artem Belevich <fbsdl...@src.cx>: > It may be worth it to look at Solaris' cyclic facillity for ideas. > sys/cddl/dev/cyclic/cyclic.c Thanks! I'll read it. 2010/3/31 Dag-Erling Smørgrav <d...@des.no>: >Never mind, Julian was making a joke at my expense. OK :D I wanna make next patch which is reflected your opinions by the end of April. Thank you! Very Truly yours Tsuyoshi Ozawa -- Tsuyoshi Ozawa <oz...@t-oza.net> _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
