Date: Tue, 07 Sep 2010 21:53:55 +0300 From: Alexander Motin <mav@FreeBSD.org> To: "Cherry G. Mathew" <cherry@zyx.in> Cc: freebsd-arch@freebsd.org Subject: Re: [resend] Re: RFC: New event timers infrastructure Message-ID: <4C868A43.6080405@FreeBSD.org> In-Reply-To: <4C864FFD.6020409@zyx.in> References: <4C0C1AE4.8050807@FreeBSD.org> <4C864FFD.6020409@zyx.in>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi. Cherry G. Mathew wrote: > On 6/6/2010 10:02 PM, Alexander Motin wrote: >> I did such things: >> - created unified timer driver's API (sys/timeet.h, kernel/kern_et.c). >> It supports global and per-CPU timers, periodic and one-shot. Provides >> driver and consumer interfaces for choosing timers and operating them; > > [...] > >> Latest patches can be found here: >> http://people.freebsd.org/~mav/et.20100606.patch > > Had you considered integrating this api with sys/timetc.h ? Most timer > devices which can interrupt after a certain period of time, can also > provide counters, I would imagine ? I don't see much reasons to do it. These systems are quite different. The almost only API intersection is device choosing algorithm and even in that case some device that is perfect as time counter can be the worst as event timer, so there indeed will be two lists independent ordered lists. Another intersection could be in using same tick periods for both time counter and event timers, but I think it will just mess code. At this moment event timers accept bintime as periods arguments and time counters also after adjustments are getting translated into bintime. It looks much more universal and transparent, especially when system uses different hardware for time counter and event timer. There is not so much hardware that can be used as both time counter and event timer. For example, on x86: - i8254 can do both, but preferably not at the same time and never both with event timer in one-shot mode; - RTC - only event timer; - LAPIC - only event timer; - HPET - both: one time counter and 3-8 event timers; - TSC - only time counter; - ACPI timer - only time counter. > I'd be keen to know your thoughts on providing the ability of et > consumers to daisy chain to a single eventtimer. I am not sure why it is needed. With my latest work on one-shot mode timers it is possible to use single timer for any number of events. At this moments for three: hardclock, statclock, proflock. They are separated for legacy reasons so I wasn't breaking it for now. Same time, if we need to have more consumers - we can either add them in the same way (bad way) or make some king of universal event scheduler for this -- like out callouts callwheel, but without tick period dependency. The last way in fact will give us really tick-less kernel. > It would be good for et_find() to query for timers that can guarantee a > specific resolution/period or below/above. I don't see problem to do it. I was just not needed. We may even allow every application to traverse that list to decide what it wants. But for present purposes I don't see enough reasons to do it. After reviewing many of our architectures I've fount that x86 probably have more timers then any other. Most of other platforms have only 1-2 timers (at least supported now or which I have found). So really complicated algorithm seems excessive there. > Finally, I'm curious to know what et_quality implies ? Perhaps it can be > an indication of the max/min resolution/period available from a given et ? There is many factors affecting "how good is this timer". Mostly it is not a question of precision. Usually it is question of functionality, performance, reliability and so on. At this moment I am manually assigning qualities in a way that allows kern_clocksource.c code to make more or less reasonable choice in most of situations. For example, RTC timer has very high granularity - prefer i8254 instead if possible; i8254 can't do one-shot mode due to being also an time counter - prefer LAPIC; if specific LAPIC timer dies in C3 state - it may be a good reason to prefer HPET. -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C868A43.6080405>