From owner-freebsd-arch@FreeBSD.ORG Mon May 24 17:01:15 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 9E66E1065672; Mon, 24 May 2010 17:01:15 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id DC6738FC1B; Mon, 24 May 2010 17:01:14 +0000 (UTC) Received: by fxm4 with SMTP id 4so3461870fxm.13 for ; Mon, 24 May 2010 10:01:13 -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=gpY8J57dimn5lzsxD3w4R1rP+1kn5uhSr0qRSjN3bog=; b=uybLgF8fHZ8s72rTTyh7aA9PQi/s998Ro/qahByMs1JVM/1vCxqmcxDaCVuq/e+pLA 9TB/Pi55iwau7WrC/P7fBwf6Wm/DwOBPcErKejltAwk1C3ZxahtGkwxipKm09UgdoqNf uq7InI0r8vQoPjKH1i7MkNb8H1DvxiL+iQXGs= 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=nImQXDo/z46S7RMaiOC0y87kufx6L0UxMzUg3UpGXjAffz/3Z5Bv7rohhXj8dCkfNb p/x6GA35LTEpRmlqAJiAB7agMsKXhwvrNo/4df1pOBS11ZIjKiVjq/N28ZyO1YyZ443e W3R4ysqh14Hq5TKGQWdidfvbSauUZy4ctZ51Q= Received: by 10.223.51.152 with SMTP id d24mr4865851fag.36.1274720473811; Mon, 24 May 2010 10:01:13 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 13sm20365488fad.19.2010.05.24.10.01.11 (version=SSLv3 cipher=RC4-MD5); Mon, 24 May 2010 10:01:12 -0700 (PDT) Sender: Alexander Motin Message-ID: <4BFAB0C5.1020002@FreeBSD.org> Date: Mon, 24 May 2010 20:00:53 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Andriy Gapon References: <4BFAA1F3.1070206@FreeBSD.org> <4BFAAA47.5060802@freebsd.org> In-Reply-To: <4BFAAA47.5060802@freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: Event timers 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: Mon, 24 May 2010 17:01:15 -0000 Andriy Gapon wrote: > on 24/05/2010 18:57 Alexander Motin said the following: >> I have defined several points on that way: >> 1*. clean low-level timer drivers from unrelated stuff, >> 2*. make some common code machine-independent, >> 3. write common driver API for event timers (alike to one we have now >> for time counters) to make adding more drivers possible, >> 4. add support for HPET as event timer in addition to time counter, >> 5. add support for timers in one-shot mode (LAPIC and HPET). > > I wonder how much you have progressed for 3,4,5. Not really much yet. Learned existing code and hardware specs, have some thought and ready to proceed. > I have some low level code for 4. I don't see much problems there, except may be interrupt allocation. But you may send it to me if there is something interesting. > Some additional things that could be useful: > a. It would be nice to replace special handling of NULL as interrupt arg with > something more convenient. Right now if interrupt arg is NULL then a pointer to > an interrupted frame is passed to interrupt handler. This is used by clock > interrupt handlers. It would be good to be able to pass both frame pointer and > some context to handler. jhb suggested that frame pointer could be passed via > struct thread. Hmmm. Interesting question... > b. On some x86 systems it is possible to broadcast APIC interrupts to all CPUs > by using broadcast ID (0xFF) instead of a specific CPU ID. This could be used > to avoid IPI overhead. > > I have some code for b. AFAIR I've heart our interrupt code not very supports it... Also IPI probably could be more selective. We could do for example some form of one-shot mode using only one simple periodic timer to wake up only needed cores (plus one initial). -- Alexander Motin