From owner-freebsd-arch@FreeBSD.ORG Thu Sep 9 09:42:37 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 AE5B61065700; Thu, 9 Sep 2010 09:42:37 +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 063608FC23; Thu, 9 Sep 2010 09:42:37 +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=AGmLDb4Y2mX6Bcgv8wHlAq0Ck8jOllmzQZM7746WVB9RuaqFcTd6J+0jl9S6zOJZTVO9vhTiMnpv6CSjewEkobc2EG/ZdI01bypiOaFbnxNuBb9tFiyDKuCe2tz/BvMt; Received: from [117.241.57.119] (helo=[127.0.0.1]) by reagan.nswebhost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OtdeM-0002Yg-Vu; Thu, 09 Sep 2010 04:42:35 -0500 Message-ID: <4C88AC08.7070502@zyx.in> Date: Thu, 09 Sep 2010 15:12:32 +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> <4C872AA4.5020906@zyx.in> <4C8738DA.80604@FreeBSD.org> In-Reply-To: <4C8738DA.80604@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 100908-1, 09/08/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 X-Mailman-Approved-At: Thu, 09 Sep 2010 11:07:58 +0000 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: Thu, 09 Sep 2010 09:42:37 -0000 Dear Alexander, On 9/8/2010 12:48 PM, Alexander Motin wrote: > > 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. > And if it is busy ? I have in mind non system timers, like stuff that comes on add-on boards, that can be exported timeret.h and interrupt the CPU. Would exporting such a timer prevent the onboard devices from utilising that specific timer function because its callback was busy ? >>> 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. > Indeed, but the abstraction could still be maintained. More practically, a flag could take care of this (TC_COUNTER_NONE or whatever. ) >> >> 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? > To summarise, My two concerns were: I) a) If there is a non-optional device specific callback (like a timer isr) tied to specific timer on a vendor board b) a "generic" non-device specific callback that uses the ET framework and acquires the timer in "a)" before the isr/callback in "a)" could obtain it. how can the API ensure that this scenario: i) doesn't happen or ii) can be subsequently rectified AND II) Did the api need to be fleshed out separately of timertc.h ? This is more of a political question that I don't care much about. Cheers, -- cherry