From owner-freebsd-arch@FreeBSD.ORG Wed Sep 8 06:18:25 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36F8410656C9; Wed, 8 Sep 2010 06:18:25 +0000 (UTC) (envelope-from cherry@zyx.in) Received: from reagan.nswebhost.com (reagan.nswebhost.com [64.22.87.10]) by mx1.freebsd.org (Postfix) with ESMTP id 7ABDF8FC13; Wed, 8 Sep 2010 06:18:24 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=zyx.in; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Antivirus:X-Antivirus-Status; b=IIGn0TfT+ZRay/k107whZWFDNr7vGyM4AwIFQqpBaQpm3aqS640Sososxkjt5HMCOMv1O2KKeKwOcklPdMb15qNQagKhf4lC4+vjo0RPH4hrWM1DZsFzbJcpW9thac7u; Received: from [117.241.57.155] (port=64486 helo=[127.0.0.1]) by reagan.nswebhost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OtDz9-0002Ye-Uq; Wed, 08 Sep 2010 01:18:21 -0500 Message-ID: <4C872AA4.5020906@zyx.in> Date: Wed, 08 Sep 2010 11:48:12 +0530 From: "Cherry G. Mathew" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Alexander Motin References: <4C0C1AE4.8050807@FreeBSD.org> <4C864FFD.6020409@zyx.in> <4C868A43.6080405@FreeBSD.org> In-Reply-To: <4C868A43.6080405@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 100907-1, 09/07/2010), Outbound message X-Antivirus-Status: Clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - reagan.nswebhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - zyx.in Cc: freebsd-arch@freebsd.org Subject: Re: [resend] Re: RFC: New event timers infrastructure X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 06:18:25 -0000 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