From owner-freebsd-arch@FreeBSD.ORG Wed Sep 8 07:19:12 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 29E3510656D6 for ; Wed, 8 Sep 2010 07:19:12 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id A01798FC0A for ; Wed, 8 Sep 2010 07:19:11 +0000 (UTC) Received: by bwz20 with SMTP id 20so5879846bwz.13 for ; Wed, 08 Sep 2010 00:19:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=MnuixKB7ahbwbxK/sC22pHXcLkPlmCmVI/SgVHYSeo4=; b=mHaRWuB8zoexIi18BD24F160eqx+sRbdNVch3EVB+A6dIuoKSyzLpSXYUWNJo7zHYi t8qOxgeGgOi9Yi1OXMnxvVPvVYe2n8P2KydR70Rx2Gkaufvq0p0rLdU8P2zmzlYJKMtd 1oyc8RkgVqFIXDIaW0ftL8FHLSJ3HozyxOkfQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=wPmysS8E9VbpDA6A1Qj3RuZkAhSoLzdy4CvLuMN56BgpHiEfe4HLnslSx1qSIvebtJ W+4dDZdm3tO+mJPDwj4LYJEX8DRX0wBVZk+ewVMnZzlFHUL01wSlDxLh1wIA/dYckTBF OlGFVQ1VK842G+P9cwOwwpPTlXmp4BbnDPvuY= Received: by 10.204.153.10 with SMTP id i10mr2034794bkw.1.1283930350492; Wed, 08 Sep 2010 00:19:10 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 24sm6031221bkr.19.2010.09.08.00.19.08 (version=SSLv3 cipher=RC4-MD5); Wed, 08 Sep 2010 00:19:09 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C8738DA.80604@FreeBSD.org> Date: Wed, 08 Sep 2010 10:18:50 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: "Cherry G. Mathew" References: <4C0C1AE4.8050807@FreeBSD.org> <4C864FFD.6020409@zyx.in> <4C868A43.6080405@FreeBSD.org> <4C872AA4.5020906@zyx.in> In-Reply-To: <4C872AA4.5020906@zyx.in> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 07:19:12 -0000 Cherry G. Mathew wrote: > On 9/8/2010 12:23 AM, Alexander Motin wrote: >> 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 ? For the most of hardware I've seen, reading doesn't need any locking. Mostly it may be needed if we will try emulate time counter using hardware that intended to be and used and event timer (like i8254). But IMHO that it dead end, and whenever it is possible, I would prefer not to do it. And even so, why locking can't be done just inside the driver if it is it's own business? At this moment I am not defining any timer locking at event timer API (kern_et.c). API only protects timer list access. Timers themselves now protected by separate lock in consumer which grabbed them (kern_clocksource.c). >> 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 ? What do you mean by daisy-chaining? For example, if we have timer supporting only periodic mode and two consumers, requiring frequencies of 100Hz and 127Hz precisely. How do you wish them to chain? What frequency write into the timer? 12700Hz? If you have no other timers to live separately - obviously you have to implement some kind of scheduling. But I believe it is the next level of abstraction, outside of present API. > btw, are there any RT constraints that the current event timer callbacks > need to be worried about ? You mean interrupt latency constraints? Except reasonable callouts time precision I don't remember other constraints. >> 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. Not sure what do you mean by "quite userland". This is low-level event timer hardware abstraction. It is not exposed to user-level and I am not sure about cases when it should be used even in kernel instead of using standard callout mechanism or it's possible further tickless successors. If you wish to work with specific event timer - you can ask et_find() to give one to you, specifying it's name, and if it is not yet busy - use if freely for whatever you want. >> 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); > } :) It will give you terrible precision or huge interrupt rate. >> - 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: I was talking about this: http://docs.freebsd.org/cgi/mid.cgi?4C7A5C28.1090904 Trivial scheduling for hardclock, statclock and proflock from single one-shot hardware event timer implemented at kern_clocksource.c. >> 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". Are you talking about callback order in case of two simultaneous events? because if events are not scheduled as simultaneous (up to 64-bit precision) they could be called respectively to that order. Question is about interrupt latency or what? -- Alexander Motin