Date: Mon, 5 Apr 2010 06:17:30 -0800 From: Tsuyoshi Ozawa <ozawa+bsd@t-oza.net> To: =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= <des@des.no>, John Baldwin <jhb@freebsd.org>, Julian Elischer <julian@elischer.org>, Artem Belevich <fbsdlist@src.cx>, Roman Divacky <rdivacky@freebsd.org>, Andriy Gapon <avg@icyb.net.ua> Cc: freebsd-hackers <freebsd-hackers@freebsd.org> Subject: Re: Dynamic ticks in FreeBSD Message-ID: <x2y411a180c1004050717nb228e573z938650d3056f7d0d@mail.gmail.com> In-Reply-To: <86iq8csmzl.fsf@ds4.des.no> References: <411a180c1003300537g2a1b4879u2d8d952ce9977cb5@mail.gmail.com> <411a180c1003300639l13d33451q305a61b2bcd6e3d5@mail.gmail.com> <20100330173504.GA70578@freebsd.org> <p2p411a180c1003310505qb6e274f2i7b39aa3dd7387d24@mail.gmail.com> <86iq8csmzl.fsf@ds4.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
Thank you for replying, and sorry for delaying to reply for my network reas= on. I'm very happy that you all give me very useful advice :D 2010/3/31 Andriy Gapon <avg@icyb.net.ua>: > 1. Instead of firing clock (LAPIC timer) interrupt regularly with a frequ= ency > 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 la= st > 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 irr= egularly. > I couldn't find any code that makes sure that the rest of the system hand= les 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' cal= lout is > scheduled after we already decided when to fire the next LAPIC timer inte= rrupt. 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 <rdivacky@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 wo= rk? Or another implementation is to make callout queue have the nearest tick va= lue. This costs O(1). > > what is the average length of the callout queue? I'm going to monitor it. 2010/3/31 Artem Belevich <fbsdlist@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 han= dling > 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 <fbsdlist@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=F8rgrav <des@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 --=20 Tsuyoshi Ozawa <ozawa@t-oza.net>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?x2y411a180c1004050717nb228e573z938650d3056f7d0d>