From owner-freebsd-current@FreeBSD.ORG Sun Jun 6 22:02:38 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 390BA106566C; Sun, 6 Jun 2010 22:02:38 +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 93BF48FC0A; Sun, 6 Jun 2010 22:02:37 +0000 (UTC) Received: by fxm20 with SMTP id 20so1992565fxm.13 for ; Sun, 06 Jun 2010 15:02:36 -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:subject:x-enigmail-version:content-type :content-transfer-encoding; bh=b02hi/AHGgC/dLyPqp+19CaduIHOBaB82C7TMR3M7ys=; b=idCPCoBIsKOhjxr9fTScpYu9kqRn3mrY3RGCmo+S96RWBxMTnA8apOtH7IW0xk+3na ZRaGlnSsI2X9fOoWdQkxDxA0db3k+hnlmMMM73A6aJDdPDbYtN4huYO37uwh/9fT98KO hqQ7x02za1h+JiGQSMS75z5dTnvEdaUS5c13Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; b=qE2phkWSJ6WNMNFEVl9RmONQ6W9zL5gCZ7Pruidw11RDY0DSLImSsDlfpXnVsp0RgE p1JrK4TfYWpNoqUniWdJQejP9VD/70R9U/buog0ZljsxYOGeZLhN2QPeVRKAe2lM3nBr g6UwgLFDidwJU+88E55zpS6W3qqPTQWDKR+Ok= Received: by 10.223.144.77 with SMTP id y13mr14340766fau.86.1275861756631; Sun, 06 Jun 2010 15:02:36 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id r25sm17028871fai.23.2010.06.06.15.02.35 (version=SSLv3 cipher=RC4-MD5); Sun, 06 Jun 2010 15:02:36 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C0C1AE4.8050807@FreeBSD.org> Date: Mon, 07 Jun 2010 01:02:12 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: FreeBSD-Current , freebsd-arch@freebsd.org X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: Subject: RFC: New event timers infrastructure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jun 2010 22:02:38 -0000 Hi. Most of x86 systems now has at least 4 types of event timers: i8254, RTC, LAPIC and HPET. Respective code in kernel is very tangled, heavily hardcoded and absolutely not scalable. I have reimplemented it, trying to solve these issues. 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; - cleaned existing x86 event timer driver's code and modified it for new API (x86/isa/atrtc.c, x86/isa/clock.c, x86/x86/local_apic.c). LAPIC timer is now per-CPU and supports both periodic and one-shot modes; - extended HPET driver to support it's event timers in periodic and one-shot mode (dev/acpica/acpi_hpet.c). Support for per-CPU operation and FSB interrupts planned for later; - written mostly machine-independent mid-layer for managing any present timers to provide clocks needed for kernel (x86/x86/timeevents.c). It supports both global and per-CPU timers. Now it supports only periodic mode, but one-shot mode support planned for later. All this stuff deeply configurable via both loader tunables on boot and sysctls in real time: %sysctl kern.eventtimer kern.eventtimer.choice: LAPIC(500) HPET(400) HPET1(390) HPET2(390) i8254(100) RTC(0) kern.eventtimer.et.LAPIC.flags: 7 kern.eventtimer.et.LAPIC.frequency: 99752386 kern.eventtimer.et.LAPIC.quality: 500 kern.eventtimer.et.HPET.flags: 3 kern.eventtimer.et.HPET.frequency: 14318180 kern.eventtimer.et.HPET.quality: 400 kern.eventtimer.et.HPET1.flags: 3 kern.eventtimer.et.HPET1.frequency: 14318180 kern.eventtimer.et.HPET1.quality: 390 kern.eventtimer.et.HPET2.flags: 3 kern.eventtimer.et.HPET2.frequency: 14318180 kern.eventtimer.et.HPET2.quality: 390 kern.eventtimer.et.RTC.flags: 1 kern.eventtimer.et.RTC.frequency: 32768 kern.eventtimer.et.RTC.quality: 0 kern.eventtimer.et.i8254.flags: 1 kern.eventtimer.et.i8254.frequency: 1193182 kern.eventtimer.et.i8254.quality: 100 kern.eventtimer.timer2: NONE kern.eventtimer.timer1: i8254 kern.eventtimer.singlemul: 2 By default system chooses two timers with highest "quality" for hardclock and statclock/profclock. User may affect that choice via disabling unwanted drivers and/or via direct specification of wanted ones. It is possible to change timers on-flight via sysctls: %sysctl kern.eventtimer.timer1=hpet kern.eventtimer.timer1: i8254 -> HPET %sysctl kern.eventtimer.timer2=hpet1 kern.eventtimer.timer2: NONE -> HPET1 After every timer change, if two timers available, mid-layer cross-checks them, and if one of them is not functional - replaces it. If there is no second timer available, or user specified to not use it - mid-layer automatically increases rate of the first timer and divide it's frequency to satisfy system needs as good as possible. User may specify how fast he wish to run fist timer relative to hz by setting kern.eventtimer.singlemul tunable/sysctl. When profiling is active, mid-layer automatically rises respective timer frequency to about 8KHz (was 1KHz previously) and decreases it back on profiling end. All above was tested on i386 and amd64. XEN was not affected and builds fine. pc98 was slightly touched. It wasn't tested, but builds fine. It's pc98/cbus/clock.c needs respective rewrite to use new features. Other architectures are untouched, but if any of them may benefit from this functionality - it should be possible to share most of the code. Latest patches can be found here: http://people.freebsd.org/~mav/et.20100606.patch Known issues: - i8254 timer generates 18Hz interrupt rate when not used and not disabled. I haven't found a way to disable it's interrupt source while holding spinlock. - timer drivers code will need some more cleaning after interrupt handler will be able to return both argument and frame same time. Feedback is very appreciated. -- Alexander Motin