From owner-freebsd-arch@FreeBSD.ORG Sun Jun 6 22:02:38 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 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-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: 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 From owner-freebsd-arch@FreeBSD.ORG Mon Jun 7 08:13:57 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 9FA33106566C; Mon, 7 Jun 2010 08:13:57 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (mx0.hoeg.nl [IPv6:2001:4dd0:ff41::b23f:aa]) by mx1.freebsd.org (Postfix) with ESMTP id 6127B8FC0A; Mon, 7 Jun 2010 08:13:57 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id BA5DA2A28CD8; Mon, 7 Jun 2010 10:13:56 +0200 (CEST) Date: Mon, 7 Jun 2010 10:13:56 +0200 From: Ed Schouten To: Alexander Motin Message-ID: <20100607081356.GY56080@hoeg.nl> References: <4C0C1AE4.8050807@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="M6k8nCARLe14uObT" Content-Disposition: inline In-Reply-To: <4C0C1AE4.8050807@FreeBSD.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD-Current , freebsd-arch@freebsd.org Subject: 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: Mon, 07 Jun 2010 08:13:57 -0000 --M6k8nCARLe14uObT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Alexander, * Alexander Motin wrote: > 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. Just out of curiosity, how does this work relate to things like having a tickless kernel? --=20 Ed Schouten WWW: http://80386.nl/ --M6k8nCARLe14uObT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkwMqkQACgkQ52SDGA2eCwXf+wCfZL6hoTiCdRknzG2JCQlDuasg MqsAmwQiGKF5hIKzba6mmA0LCgJnAeRw =3Wyp -----END PGP SIGNATURE----- --M6k8nCARLe14uObT-- From owner-freebsd-arch@FreeBSD.ORG Mon Jun 7 08:27:07 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 A8640106564A; Mon, 7 Jun 2010 08:27:07 +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 0B7148FC15; Mon, 7 Jun 2010 08:27:06 +0000 (UTC) Received: by fxm20 with SMTP id 20so2199060fxm.13 for ; Mon, 07 Jun 2010 01:27:06 -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=hokCZQiAoVDrD2azQzl4La/7kMOlQq6yn3iUEi7aL+8=; b=ZDnV1/dSvERpFZsV14TCndIaJCW3aaI/aXpx9oJ2TAeQQtB2Y9yQyALID9706ec2jk S68lB/dMSk/wyoYKDtN8WtqA6uadfHb8qjD3leRh2sVAZE/MQcCXDrBSQ05EBFQhBwQM 2VvezoZTkPty7blbRQBd/zsbv//XEl0RYb8QQ= 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=Adz84OhPeE8X1q5ntwefzaDpruyEWhviNzTdXgOiuY7SHVVWbN0yuRw7/W/onO+hsx zxeQUTasMPJzcXwbMJIjHi9FIS73kghrQkJt0ScMM6KohL6+XEaEXY5fzDG7MQbuAttz W/9WArpqO2KE7D0akuH8bOtxAT29/6OB/Ewlw= Received: by 10.223.26.206 with SMTP id f14mr14743331fac.96.1275899225958; Mon, 07 Jun 2010 01:27:05 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 2sm19184799fav.13.2010.06.07.01.27.04 (version=SSLv3 cipher=RC4-MD5); Mon, 07 Jun 2010 01:27:05 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C0CAD43.20102@FreeBSD.org> Date: Mon, 07 Jun 2010 11:26:43 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Ed Schouten References: <4C0C1AE4.8050807@FreeBSD.org> <20100607081356.GY56080@hoeg.nl> In-Reply-To: <20100607081356.GY56080@hoeg.nl> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current , freebsd-arch@freebsd.org Subject: 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: Mon, 07 Jun 2010 08:27:07 -0000 Ed Schouten wrote: > * Alexander Motin wrote: >> 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. > > Just out of curiosity, how does this work relate to things like having a > tickless kernel? It is almost mandatory prerequisite. We can't do any fancy timer stuff without unified timer API. Tsuyoshi Ozawa in his Dynamic Ticks work also got to the same conclusion, but he was much less aggressive in rewriting legacy code. -- Alexander Motin From owner-freebsd-arch@FreeBSD.ORG Mon Jun 7 10:34:11 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 D80561065675; Mon, 7 Jun 2010 10:34:11 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (mx0.hoeg.nl [IPv6:2001:4dd0:ff41::b23f:aa]) by mx1.freebsd.org (Postfix) with ESMTP id 99DF28FC39; Mon, 7 Jun 2010 10:34:11 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id EAF702A28CD8; Mon, 7 Jun 2010 12:34:10 +0200 (CEST) Date: Mon, 7 Jun 2010 12:34:10 +0200 From: Ed Schouten To: Alexander Motin Message-ID: <20100607103410.GZ56080@hoeg.nl> References: <4C0C1AE4.8050807@FreeBSD.org> <20100607081356.GY56080@hoeg.nl> <4C0CAD43.20102@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/IS0x6j0ns1j6BpZ" Content-Disposition: inline In-Reply-To: <4C0CAD43.20102@FreeBSD.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD-Current , freebsd-arch@freebsd.org Subject: 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: Mon, 07 Jun 2010 10:34:11 -0000 --/IS0x6j0ns1j6BpZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Alexander, * Alexander Motin wrote: > Ed Schouten wrote: > > Just out of curiosity, how does this work relate to things like having a > > tickless kernel? >=20 > It is almost mandatory prerequisite. We can't do any fancy timer stuff > without unified timer API. Tsuyoshi Ozawa in his Dynamic Ticks work also > got to the same conclusion, but he was much less aggressive in rewriting > legacy code. That's just what I wanted to hear. Thanks! --=20 Ed Schouten WWW: http://80386.nl/ --/IS0x6j0ns1j6BpZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkwMyyIACgkQ52SDGA2eCwVMIgCeNGmb+AQG0MtUQ3D5+TYKWity YuIAn2z3AWWGBY5N+XJhgTNvlxY9wXiT =X7am -----END PGP SIGNATURE----- --/IS0x6j0ns1j6BpZ-- From owner-freebsd-arch@FreeBSD.ORG Tue Jun 8 05:47:27 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 1EF6B106566C; Tue, 8 Jun 2010 05:47:27 +0000 (UTC) (envelope-from ozawa@t-oza.net) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 564768FC21; Tue, 8 Jun 2010 05:47:25 +0000 (UTC) Received: by wwb22 with SMTP id 22so4188866wwb.13 for ; Mon, 07 Jun 2010 22:47:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.182.7 with SMTP id n7mr3077481wem.91.1275974669494; Mon, 07 Jun 2010 22:24:29 -0700 (PDT) Received: by 10.216.185.12 with HTTP; Mon, 7 Jun 2010 22:24:29 -0700 (PDT) X-Originating-IP: [27.230.160.181] Received: by 10.216.185.12 with HTTP; Mon, 7 Jun 2010 22:24:29 -0700 (PDT) In-Reply-To: References: <4C0C1AE4.8050807@FreeBSD.org> Date: Mon, 7 Jun 2010 21:24:29 -0800 Message-ID: From: Tsuyoshi Ozawa To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD-Current , freebsd-arch@freebsd.org Subject: 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, 08 Jun 2010 05:47:27 -0000 2010/6/6, Alexander Motin : > 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 > This is excellent! I'll try this to apply this patch and rewrite my old dynamic ticks code to fit this event timer API . Thank you, Alexander ! -- Tsuyoshi Ozawa 2010/06/07 7:03 "Alexander Motin" : 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 From owner-freebsd-arch@FreeBSD.ORG Tue Jun 8 14:06:07 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 CE73F106566C; Tue, 8 Jun 2010 14:06:07 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-yw0-f182.google.com (mail-yw0-f182.google.com [209.85.211.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5DB438FC23; Tue, 8 Jun 2010 14:06:07 +0000 (UTC) Received: by ywh12 with SMTP id 12so3337230ywh.14 for ; Tue, 08 Jun 2010 07:06:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0Lps0RBloQ/dEHpYgMnL5AS2Yzqli+7NPkNobv2w+ak=; b=C0Qx2VihVzcu4Sn9ri/wJZiiw8ef2kpk0i9sTQ5CaHZjbIJbSlTCGPhsRGCxSWbkRO Ib/+vPPUmvrEA8QCM+7bYt50LuIrd4RdqvqhOCs5HwVJ77e7XgntXqFPAxhhgbSVxv/9 dCXJsXziQrEap2+LfjwCfsd2pRaOExP49RP4Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=w/8pN8OxTOvlqPI3M0TPVZycBLsNWbAXeKdB7kw2clJ1vyEjGBAYhxo85Uoty7ls7N dtKty+zJaiMNq+7aNFsyf1qRUozU7jeXf0H3iM1hOwTPDp4UkU/m+rQezpAzDlBWWNId ADtGo2VVzRywe2e9CEv+KWSPg+TJCUlyD29Xg= MIME-Version: 1.0 Received: by 10.101.177.16 with SMTP id e16mr16125636anp.221.1276005966451; Tue, 08 Jun 2010 07:06:06 -0700 (PDT) Received: by 10.231.182.196 with HTTP; Tue, 8 Jun 2010 07:06:06 -0700 (PDT) In-Reply-To: References: <4C0C1AE4.8050807@FreeBSD.org> Date: Tue, 8 Jun 2010 09:06:06 -0500 Message-ID: From: Brandon Gooch To: Tsuyoshi Ozawa Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Alexander Motin , FreeBSD-Current , freebsd-arch@freebsd.org Subject: 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, 08 Jun 2010 14:06:07 -0000 On Tue, Jun 8, 2010 at 12:24 AM, Tsuyoshi Ozawa wrote: > 2010/6/6, Alexander Motin : >> 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: >> =A0- 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; >> =A0- 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; >> =A0- 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; >> =A0- written mostly machine-independent mid-layer for managing any prese= nt >> 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=3Dhpet >> kern.eventtimer.timer1: i8254 -> HPET >> %sysctl kern.eventtimer.timer2=3Dhpet1 >> 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: >> =A0- 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. >> =A0- 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 >> > > This is excellent! > I'll try this to apply this patch and =A0rewrite my old dynamic ticks cod= e to > fit this event timer API . > > Thank you, Alexander ! > -- > Tsuyoshi Ozawa > > > 2010/06/07 7:03 "Alexander Motin" : > > 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: > =A0- 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; > =A0- 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; > =A0- 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; > =A0- written mostly machine-independent mid-layer for managing any presen= t > 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=3Dhpet > kern.eventtimer.timer1: i8254 -> HPET > %sysctl kern.eventtimer.timer2=3Dhpet1 > 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: > =A0- 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. > =A0- 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 This is an exciting advance for FreeBSD, and I'm looking forward to testing the new infrastructure code. Alexander, do you feel that the code is at a stage where meaningful user testing can occur? Tsuyoshi, will you be providing code to Alexander to integrate into his patch(es), or will your development continue as a separate effort? Thank you both so much for taking on this task! -Brandon From owner-freebsd-arch@FreeBSD.ORG Tue Jun 8 14:40:32 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 60667106567A; Tue, 8 Jun 2010 14:40:32 +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 982638FC12; Tue, 8 Jun 2010 14:40:31 +0000 (UTC) Received: by fxm20 with SMTP id 20so3667508fxm.13 for ; Tue, 08 Jun 2010 07:40:30 -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=3CUoreN7sS8aNXzlPkj4WRlLIDfwdLjwYcuQqGEBLjM=; b=DP8eZc1BihsyNUhCKpdkruYjYHPPLNOh6CtAdnRtWlCjGGWrmhLEakouCjlX7G5odP AJaVQQ2+GvBfAjMtpinNmaX6M7FDpCy12B1JvcsafromsXhTG/roLZIonYQIeXmEK1VE wQol1vX58/uapM+uXL7uJYijv99XAIe8DyuKY= 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=Ma8/wvnjGKlaTe8/+IHaHKfbAUB4qa5VkCbPV+IsmzZ4T1ewo2UPDN7s1jE+xEoc8I vXMECEYnGdV92DlD7msbikxYE89JW0ab+zdkdwlO+mzR98hfE+V6SZ2SYNrvH1J22zFQ 3FlQlxov9GpahD6b0ntTIcxWITMi0z5CVkwuc= Received: by 10.223.92.152 with SMTP id r24mr1113893fam.74.1276008030380; Tue, 08 Jun 2010 07:40:30 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id r12sm25747930fah.8.2010.06.08.07.40.28 (version=SSLv3 cipher=RC4-MD5); Tue, 08 Jun 2010 07:40:28 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C0E5646.1060007@FreeBSD.org> Date: Tue, 08 Jun 2010 17:40:06 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Brandon Gooch References: <4C0C1AE4.8050807@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org, FreeBSD-Current , Tsuyoshi Ozawa Subject: 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, 08 Jun 2010 14:40:32 -0000 Brandon Gooch wrote: > Alexander, do you feel that the code is at a stage where meaningful > user testing can occur? I think yes. I've touched a lot of legacy code, so it would be nice to know what I may have broken. For example, i8254 and RTC drivers now more dependent on attaching to PnP/ACPI reported hardware. I am not sure if there still any legacy system which not doing that. The oldest system I have tested was P-III Celeron. Unluckily my small development SSD is too "large" for my Pentium board's BIOS. :) There is still work planned, but I hope it won't require major changes in already written code. -- Alexander Motin From owner-freebsd-arch@FreeBSD.ORG Tue Jun 8 15:58:02 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 454D71065672; Tue, 8 Jun 2010 15:58:02 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 02D4D8FC08; Tue, 8 Jun 2010 15:58:01 +0000 (UTC) Received: by pvh11 with SMTP id 11so2559734pvh.13 for ; Tue, 08 Jun 2010 08:58:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=UXgmN1UzaYgHE4Bt5m484wK71VAAimbQQnNOSJbzUhM=; b=KnhC9i4cKJNlb5681dsdLWpMWc56WbghkYDerzw6KCbTBd+xzlMEyDEiLBOLymPAXa lzisytDm46PwDRXP/4RlmDqGJni58fLfgv0apo5ZkcFZHjhu9pG1z857y2FuZmZfk72z V7VY1I9GLS/csBN/oH8eXFE8ATQjer9dFxg5Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Jw5iFxvDzLKNbKATOIkeq0njVarf4gimFFA9MOI3zYNG6dMfc/FARbuMgpmxA2jobI V32wHR9RtGXfKpjSw7PzA34HLdges7BPzfQNw33EaaQKk8CEZUDE3zLhNHWT56K25Wt9 uTyf0sgUAfXHw2vb5uz0E15UvHpKa2USKe1pM= MIME-Version: 1.0 Received: by 10.229.183.198 with SMTP id ch6mr3555809qcb.243.1276012680632; Tue, 08 Jun 2010 08:58:00 -0700 (PDT) Received: by 10.231.182.196 with HTTP; Tue, 8 Jun 2010 08:58:00 -0700 (PDT) In-Reply-To: <4C0E5646.1060007@FreeBSD.org> References: <4C0C1AE4.8050807@FreeBSD.org> <4C0E5646.1060007@FreeBSD.org> Date: Tue, 8 Jun 2010 10:58:00 -0500 Message-ID: From: Brandon Gooch To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arch@freebsd.org, FreeBSD-Current , Tsuyoshi Ozawa Subject: 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, 08 Jun 2010 15:58:02 -0000 On Tue, Jun 8, 2010 at 9:40 AM, Alexander Motin wrote: > Brandon Gooch wrote: >> Alexander, do you feel that the code is at a stage where meaningful >> user testing can occur? > > I think yes. I've touched a lot of legacy code, so it would be nice to > know what I may have broken. For example, i8254 and RTC drivers now more > dependent on attaching to PnP/ACPI reported hardware. I am not sure if > there still any legacy system which not doing that. The oldest system I > have tested was P-III Celeron. Unluckily my small development SSD is too > "large" for my Pentium board's BIOS. :) > > There is still work planned, but I hope it won't require major changes > in already written code. > > -- > Alexander Motin > I'm giving http://people.freebsd.org/~mav/et.20100607.patch a go right now... After patching and recompiling the kernel, I'm up and running. What information/feedback would you like to see from us users? -Brandon From owner-freebsd-arch@FreeBSD.ORG Tue Jun 8 20:19:43 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 D2C0C106564A; Tue, 8 Jun 2010 20:19:43 +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 330DE8FC14; Tue, 8 Jun 2010 20:19:42 +0000 (UTC) Received: by fxm20 with SMTP id 20so3984820fxm.13 for ; Tue, 08 Jun 2010 13:19:42 -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=AIFR8WscTJoZC9QH70qW301lzchG9LWkyC0vRwcr0+0=; b=S9WsG+4/CZCRwkt0fTevLrIw3cmzFFuu0nmHRvinq8p14XO2HJpi4nx+gVT0eTnsoD u6QB7h1she+7GfKc1NkuRh/P5n+sH1ZM63AUrqi3vljxw6e9C8QqCuAbYAs8MUMfEpoB P+wggsviaKxI4MSKk6sZqtiiFCgwKZGvo5vtc= 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=l21b7Dlc0+RnKcDEuOgmnR689e/Mz+Dsu7HK46YdJ3pMUaHeWL6UupMjduYP7MAHp0 69MXc5WNIU4rOOrnxQ7WixSNWBu1Uiz+vPZbJnzsKtdEKv7gnysHDfYifGshSHI9FPKX 9loP3bMMcMXxpn2oGjZRSGqSPjvoqqi2mBd0M= Received: by 10.223.144.77 with SMTP id y13mr754381fau.86.1276028382146; Tue, 08 Jun 2010 13:19:42 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id y12sm589617faj.5.2010.06.08.13.19.40 (version=SSLv3 cipher=RC4-MD5); Tue, 08 Jun 2010 13:19:41 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C0EA5C7.7000802@FreeBSD.org> Date: Tue, 08 Jun 2010 23:19:19 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Brandon Gooch References: <4C0C1AE4.8050807@FreeBSD.org> <4C0E5646.1060007@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org, FreeBSD-Current , Tsuyoshi Ozawa Subject: 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, 08 Jun 2010 20:19:43 -0000 Brandon Gooch wrote: > I'm giving http://people.freebsd.org/~mav/et.20100607.patch a go right now... > > After patching and recompiling the kernel, I'm up and running. > > What information/feedback would you like to see from us users? As always: what is working and especially what is not. What timers detected on system, what are used, are all of them running, and if not, does system automatically falls back to different ones, is there any problems with choosing timers manually in different combinations, does suspend/resume still working... -- Alexander Motin From owner-freebsd-arch@FreeBSD.ORG Thu Jun 10 16:04:51 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 554EA1065673; Thu, 10 Jun 2010 16:04:51 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 090AD8FC0A; Thu, 10 Jun 2010 16:04:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o5AFtAK8038649; Thu, 10 Jun 2010 09:55:10 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 10 Jun 2010 09:55:13 -0600 (MDT) Message-Id: <20100610.095513.951589869037607611.imp@bsdimp.com> To: mav@freebsd.org From: "M. Warner Losh" In-Reply-To: <4C0E5646.1060007@FreeBSD.org> References: <4C0E5646.1060007@FreeBSD.org> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: jamesbrandongooch@gmail.com, ozawa@t-oza.net, freebsd-current@freebsd.org, freebsd-arch@freebsd.org Subject: 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, 10 Jun 2010 16:04:51 -0000 In message: <4C0E5646.1060007@FreeBSD.org> Alexander Motin writes: : Brandon Gooch wrote: : > Alexander, do you feel that the code is at a stage where meaningful : > user testing can occur? : : I think yes. I've touched a lot of legacy code, so it would be nice to : know what I may have broken. For example, i8254 and RTC drivers now more : dependent on attaching to PnP/ACPI reported hardware. I am not sure if : there still any legacy system which not doing that. The oldest system I : have tested was P-III Celeron. Unluckily my small development SSD is too : "large" for my Pentium board's BIOS. :) The only issue I'm aware of is that on older systems PnP and ACPI can sometimes interfere. But I thought we'd fixed those issues... I can test on my older pentium too... Warner : There is still work planned, but I hope it won't require major changes : in already written code. : : -- : Alexander Motin : _______________________________________________ : freebsd-current@freebsd.org mailing list : http://lists.freebsd.org/mailman/listinfo/freebsd-current : To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" : From owner-freebsd-arch@FreeBSD.ORG Sat Jun 12 03:33:50 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D36C1065670 for ; Sat, 12 Jun 2010 03:33:50 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3FBE58FC15 for ; Sat, 12 Jun 2010 03:33:49 +0000 (UTC) Received: by pwi3 with SMTP id 3so326080pwi.13 for ; Fri, 11 Jun 2010 20:33:49 -0700 (PDT) Received: by 10.141.90.21 with SMTP id s21mr2112121rvl.118.1276313629653; Fri, 11 Jun 2010 20:33:49 -0700 (PDT) Received: from [10.0.1.198] (udp022762uds.hawaiiantel.net [72.234.79.107]) by mx.google.com with ESMTPS id l29sm1952901rvb.16.2010.06.11.20.33.48 (version=SSLv3 cipher=RC4-MD5); Fri, 11 Jun 2010 20:33:49 -0700 (PDT) Date: Fri, 11 Jun 2010 17:34:27 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: arch@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Subject: Change to config(8) for OFED 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: Sat, 12 Jun 2010 03:33:50 -0000 Hi Folks, I have a patch to permit compilation of files brought in from linux that use the same name in multiple directories. I added a new directive called 'obj-prefix' which expects a quoted string that will be prepended to the object file name. The problem is that this breaks ${.IMPSRC} I could also emit the source file name for those rules which are created with prefixes and then require each file that uses a prefix to also use compile-with. This wouldn't be so bad since they likely are already using compile-with anyway. Any other suggestions? Can I override IMPSRC? Thanks, Jeff From owner-freebsd-arch@FreeBSD.ORG Sat Jun 12 14:31:00 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 020851065670; Sat, 12 Jun 2010 14:31:00 +0000 (UTC) (envelope-from oliver.pntr@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 54D748FC1E; Sat, 12 Jun 2010 14:30:58 +0000 (UTC) Received: by bwz2 with SMTP id 2so1348728bwz.13 for ; Sat, 12 Jun 2010 07:30:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=fiGs3TC6r782xCiEtKAi225ygKQ5Oy11Q0A+9xgjxqQ=; b=xV1UmCWgg2EBcbdFM6DUpRizPnfnmU9X28mBDQHDqKJderDKblPvvkBUP18HehPj5t gygZrhO1V6jRP9LYoQh3TFwXAGANBJvjEYFCpxA5/a2ogEIvZJM5C9KwWACuchM7VacE NC2eIG1IIjG0FkY3ij6zan5SnfzmsEMtEpIm8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=kxsJZ1ahpHbyU98Dm4JZ7kix7IL5kTCqNmhTyrdpl75+K2PIj4tGc8T1zsBj/AFSs9 INEwCMDChbflrMK2vBaA3zjPr1PUmNiWi4COaCbnv0Ks86SkDEfheWroMO3NRMwSuvV5 km0GEkO8NbhfLACSG3XKIFASnfXPfJjGBsSBE= MIME-Version: 1.0 Received: by 10.204.81.220 with SMTP id y28mr2352378bkk.149.1276351384432; Sat, 12 Jun 2010 07:03:04 -0700 (PDT) Received: by 10.204.100.5 with HTTP; Sat, 12 Jun 2010 07:03:04 -0700 (PDT) Date: Sat, 12 Jun 2010 16:03:04 +0200 Message-ID: From: Oliver Pinter To: arch@freebsd.org, freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Robert Watson , ssouhlal@FreeBSD.org Subject: stackgap 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: Sat, 12 Jun 2010 14:31:00 -0000 Hi All! The linked[1][2] stackgap patches why not included in FreeBSD tree? I used this patches for a long while (~2 year ago), without problem. And I have an updated patch for 7-STABLE: http://peonia.teteny.elte.hu/freebsd/patches/stable/stable/20091229025818-randomize_mmap.patch [1] http://people.freebsd.org/~ssouhlal/testing/stackgap-20050527.diff [2] http://unix.derkeiler.com/Mailing-Lists/FreeBSD/arch/2005-05/0109.html Thanks, Oliver From owner-freebsd-arch@FreeBSD.ORG Sat Jun 12 16:14:59 2010 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE3A21065675 for ; Sat, 12 Jun 2010 16:14:59 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 67EA28FC08 for ; Sat, 12 Jun 2010 16:14:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o5CGEuhj010067; Sat, 12 Jun 2010 10:14:57 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 12 Jun 2010 10:14:58 -0600 (MDT) Message-Id: <20100612.101458.10150326125744273.imp@bsdimp.com> To: jroberson@jroberson.net From: "M. Warner Losh" In-Reply-To: References: X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org Subject: Re: Change to config(8) for OFED 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: Sat, 12 Jun 2010 16:14:59 -0000 In message: Jeff Roberson writes: : I have a patch to permit compilation of files brought in from linux : that use the same name in multiple directories. I added a new : directive called 'obj-prefix' which expects a quoted string that will : be prepended to the object file name. The problem is that this breaks : ${.IMPSRC} So foo_bar.o depends on bar.c? And ${.IMPSRC} expands to foo_bar.c? : I could also emit the source file name for those rules which are : created with prefixes and then require each file that uses a prefix to : also use compile-with. This wouldn't be so bad since they likely are : already using compile-with anyway. You'll have to emit compile rules, I think. : Any other suggestions? Can I override IMPSRC? No. ${.IMPSRC} isn't wrong, it just isn't what you want it to be, so you have to override the rules. Warner From owner-freebsd-arch@FreeBSD.ORG Sat Jun 12 17:18:07 2010 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D24021065678 for ; Sat, 12 Jun 2010 17:18:07 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 3634F8FC12 for ; Sat, 12 Jun 2010 17:18:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o5CHI30O010492; Sat, 12 Jun 2010 11:18:03 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 12 Jun 2010 11:18:05 -0600 (MDT) Message-Id: <20100612.111805.94843338670897167.imp@bsdimp.com> To: jroberson@jroberson.net From: "M. Warner Losh" In-Reply-To: <20100612.101458.10150326125744273.imp@bsdimp.com> References: <20100612.101458.10150326125744273.imp@bsdimp.com> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org Subject: Re: Change to config(8) for OFED 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: Sat, 12 Jun 2010 17:18:07 -0000 In message: <20100612.101458.10150326125744273.imp@bsdimp.com> "M. Warner Losh" writes: : In message: : Jeff Roberson writes: : : I have a patch to permit compilation of files brought in from linux : : that use the same name in multiple directories. I added a new : : directive called 'obj-prefix' which expects a quoted string that will : : be prepended to the object file name. The problem is that this breaks : : ${.IMPSRC} : : So foo_bar.o depends on bar.c? And ${.IMPSRC} expands to foo_bar.c? : : : I could also emit the source file name for those rules which are : : created with prefixes and then require each file that uses a prefix to : : also use compile-with. This wouldn't be so bad since they likely are : : already using compile-with anyway. : : You'll have to emit compile rules, I think. Ideally, you'd be able to emit: foo_bar.o: $S/path/to/file/bar.c ${NORMAL_C} @${NORMAL_CTFCONVERT} but NORMAL_C is NORMAL_C= ${CC} -c ${CFLAGS} ${WERROR} ${PROF} ${.IMPSRC} and .IMPSRC is null. That seems like a bug to me, but I'm not sure if the bug is that .IMPSRC is computed wrong, or if it really should be ${.ALLSRC} Warner From owner-freebsd-arch@FreeBSD.ORG Sat Jun 12 18:49:33 2010 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21DDA1065670 for ; Sat, 12 Jun 2010 18:49:33 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id D89558FC1F for ; Sat, 12 Jun 2010 18:49:32 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id D19741FFC33; Sat, 12 Jun 2010 18:49:31 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id AD45A84492; Sat, 12 Jun 2010 20:47:21 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "M. Warner Losh" References: <20100612.101458.10150326125744273.imp@bsdimp.com> <20100612.111805.94843338670897167.imp@bsdimp.com> Date: Sat, 12 Jun 2010 20:47:21 +0200 In-Reply-To: <20100612.111805.94843338670897167.imp@bsdimp.com> (M. Warner Losh's message of "Sat, 12 Jun 2010 11:18:05 -0600 (MDT)") Message-ID: <86zkz05bra.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: arch@FreeBSD.org Subject: Re: Change to config(8) for OFED 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: Sat, 12 Jun 2010 18:49:33 -0000 "M. Warner Losh" writes: > but NORMAL_C is > > NORMAL_C=3D ${CC} -c ${CFLAGS} ${WERROR} ${PROF} ${.IMPSRC} > > and .IMPSRC is null. That seems like a bug to me, but I'm not sure if > the bug is that .IMPSRC is computed wrong, or if it really should be > ${.ALLSRC} .IMPSRC is the *implicit* source and is only valid in *implicit* rules. Consider the following: .SUFFIXES: .foo .bar .foo.bar: foo2bar.sh /bin/sh foo2bar.sh ${.IMPSRC} ${.TARGET} When building hello.bar from hello.foo, .IMPSRC is "hello.foo" but .ALLSRC is "hello.foo foo2bar.sh". GNU make has a way of defining more complex implicit rules (pattern rules). If we had something similar, we could do: foo_%.o: %.c ${NORMAL_C} DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no