Date: Wed, 08 Sep 2010 11:48:12 +0530 From: "Cherry G. Mathew" <cherry@zyx.in> To: Alexander Motin <mav@FreeBSD.org> Cc: freebsd-arch@freebsd.org Subject: Re: [resend] Re: RFC: New event timers infrastructure Message-ID: <4C872AA4.5020906@zyx.in> In-Reply-To: <4C868A43.6080405@FreeBSD.org> References: <4C0C1AE4.8050807@FreeBSD.org> <4C864FFD.6020409@zyx.in> <4C868A43.6080405@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 9/8/2010 12:23 AM, Alexander Motin wrote: > 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, I am not so sure this is as bad as it sounds. For eg: wouldn't a specific driver backend, like, say the attimer need to protect against concurrent port writes via both APIs, eg: from a oneshot event expiry callback and an asynchronous counter read callback (from the separate APIs) ? And surely, there is some correlation between timer counter resolution and event callback period "quality" for a given device ? I do see the cleanliness of abstraction you're arguing for, but I'm just saying this is perhaps a bit over-engineered ? > so there indeed will be two lists independent > ordered lists. > Or alternatively, daisy-chained callbacks ? You could have clients daisy-chaining callbacks on top of specific timecounters they care about ? btw, are there any RT constraints that the current event timer callbacks need to be worried about ? > 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. > I agree that the abstractions are "clean"er. However, this isn't quite userland, is it ? I'm thinking of the case in which a specific hardware topology requires a driver to talk to a specific timer device, say, on an add-on board of some sort. > 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; An ideal opportunity to implement: { mtx_lock_spin(&clock_lock); softcounter++; mtx_unlock_spin(&clock_lock); } :-) > - 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, This is in yet unpublished work, right ? 'cause I see: +int +et_init(struct eventtimer *et, et_event_cb_t *event, + et_deregister_cb_t *deregister, void *arg) +{ + + if (event == NULL) + return (EINVAL); + if (et->et_active) + return (EBUSY); ... > 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. > I think the key thing I'm worried about here is consumer order. Is there a way in which this can be queried/set by consumers ? I imagine a generic scheduler would abstract this decision away from consumers as a "scheduling policy". >> 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. > Okay. I was thinking in the context of a wider consumer audience. >> 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. > Many thanks for the detailed explanation. -- cherry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C872AA4.5020906>