From owner-freebsd-arch@FreeBSD.ORG Tue Sep 7 19:19:41 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 2E2731065696 for ; Tue, 7 Sep 2010 19:19:41 +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 AAA7C8FC1A for ; Tue, 7 Sep 2010 19:19:40 +0000 (UTC) Received: by bwz20 with SMTP id 20so5352282bwz.13 for ; Tue, 07 Sep 2010 12:19:39 -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=VQSdAfqXWjrcwJwD2pKu/7PJ36Dv2+vnfExsfcZ7Jdw=; b=XNAas9Lr6rFB9cTppzqPsgTUi+wTUCkGoI1qhv/IY6MBWH5eVTE5BUD0kg8oYEe+SJ QVgiRWmYM6IjlCwYhJWCOCkb4iWnbJqlcVJetvgoCg9n6axsTF9GmcXeF5uKlfEkqPNR 10q4Mzh4wwm+DrcF8KtxaPk6D7F1LfeKUQx7k= 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=LtJaFzQL0PCDyRRjCS+ki1S4neVcUVGlpAJoyZCcZ0utvppPCSyUoGT5yL7+vMcQ+a jcyXM9N/gVZXh2Z4qZCkG2NYADRCAhAzR27iYntFcvLjbAQUVRydZZXf8z9fs06Ywi0O OKG2XLw3BTqwEU0t1Te9Y6qhVOZmX7S+xvNuE= Received: by 10.204.141.16 with SMTP id k16mr1166976bku.177.1283885656040; Tue, 07 Sep 2010 11:54:16 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id g12sm5556278bkb.2.2010.09.07.11.54.13 (version=SSLv3 cipher=RC4-MD5); Tue, 07 Sep 2010 11:54:14 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C868A43.6080405@FreeBSD.org> Date: Tue, 07 Sep 2010 21:53:55 +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> In-Reply-To: <4C864FFD.6020409@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: Tue, 07 Sep 2010 19:19:41 -0000 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