From owner-freebsd-arch@FreeBSD.ORG Sun Jun 20 15:47:44 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 480CA106566C; Sun, 20 Jun 2010 15:47:44 +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 9C3468FC12; Sun, 20 Jun 2010 15:47:43 +0000 (UTC) Received: by fxm7 with SMTP id 7so1833723fxm.13 for ; Sun, 20 Jun 2010 08:47: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=j8gugJJTHNUqrKjlX7/5E6lqQc0hBxwN1te/4sMU+ww=; b=JtZ+R7BoiZf84h4z/A5gV4CWv3KkEsW02/lfi2AMzsK0zOmBwjzyF2ooGrqqCXK+9h PPSJ+vbeCRBu/H9xfVTCJF4k7bhgIRdi00KVFh//A+tt/XOL5oljqNX9jdvQ7nKt0gpV QavKm6iaw9hCX/AxXQGISzsZnCBxfm2wLB/p8= 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=jSZdlzqds3K830EK8XtMyhG9synxQXUhMqT/ataRxIXv56BmOx9F9TaN+DDVhSDAYF v1ZmJ2gAKoMlYJ8OmOoGzpU+xPXhDuiD9GEvO5w/PBAPiUj9bhqbPgEQeQvvfXjX/D3V 9LvTG2yGELGxk2vYl53cgxthdwj7reKIVaBDk= Received: by 10.223.21.22 with SMTP id h22mr3893596fab.106.1277048862389; Sun, 20 Jun 2010 08:47:42 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id p21sm25180531fak.45.2010.06.20.08.47.41 (version=SSLv3 cipher=RC4-MD5); Sun, 20 Jun 2010 08:47:41 -0700 (PDT) Sender: Alexander Motin Message-ID: <4C1E381B.30405@FreeBSD.org> Date: Sun, 20 Jun 2010 18:47:39 +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> <4C1DB296.5040605@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-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: Sun, 20 Jun 2010 15:47:44 -0000 Brandon Gooch wrote: > On Sun, Jun 20, 2010 at 1:17 AM, Alexander Motin wrote: > In by /boot/loader.conf, I now have: > > # Power Saving > kern.hz="100" > #hint.apic.0.clock="0" > #hint.atrtc.0.clock="0" > hint.p4tcc.0.disabled="1" > hint.p4tcc.1.disabled="1" > hint.acpi_throttle.0.disabled="1" > hint.acpi_throttle.1.disabled="1" > hw.pci.do_power_nodriver="3" > > In /etc/sysctl.conf, I have as suggested: > > kern.eventtimer.timer1=HPET > kern.eventtimer.timer2=NONE > kern.eventtimer.singlemul=1 While this can be done in sysctl.conf, it would be better to do it in loader.conf to make it applied from the beginning, without on-the-fly timers change. > But in my dmesg, I see: > > # dmesg | grep Starting > Starting kernel event timers: LAPIC @ 100Hz, HPET @ 128Hz > Starting kernel event timers: LAPIC @ 400Hz, NONE @ 0Hz > Starting kernel event timers: HPET @ 200Hz, NONE @ 0Hz This is result of changing timers during late boot by sysctl.conf. > So it seems as if the HPET doesn't honor kern.hz setting? Maybe I > still need to explicitly disable the apic timers... All timers now equally honor hz. But except hz, stathz also should be honored, which set once during startup. In your case, as second timer was initially present, system was free to choose stathz frequency, and it chosen 128Hz. When you later disabled second timer, system had to rise first timer frequency to emulate declared stathz. If you move timers selection options from sysctl.conf to loader.conf you will get what you want. > Would you suggest using LAPIC as opposed to HPET? I have seen power > savings being able to use C3 state, but if tickless kernel eventually > buys those savings back, perhaps LAPIC would be better... Tickless operation usually effective only together with C-states. It increases their effectiveness (or even applicability). The only case benefit from tickless operation without C3 - is a virtual machines. So if your LAPIC dies on C3 (it seems not to on Core i5 any more) you have no much other options then avoid it. HPET same time never have problems with C-states, as it located in chipset. But not every HPET is equally useful. Except AMD since at least SB700) and latest Intel chipsets, HPET uses regular IRQs, that are often shared with PCI devices and so hardly could be bound to CPU cores to provide separate events for every core. While tickless operation is still possible in that case, it is somewhat limited, as one core will have wake up every time when any other need event. Mentioned chipset's HPETs same time support FSB interrupts (alike to PCI MSI-X), that are never shared and so timers could be dedicated to CPU cores. >> As result, you will have single timer, running at HZ rate. Instead of >> HPET there you may choose any timer: >> LAPIC - it is per-CPU, so saves on IPI interrupts, supports one-shot >> mode and so suitable for further tickless kernel, but it doesn't work in >> C3 state; > > So if LAPIC is disabled in C3 state, is there a possibility that the > "on-the-fly" method of changing clocks could kick in when the CPU > enters C3 state, switching to the HPET when it happens? On-the-fly timers change is possible, as you have already tried with sysctl.conf. But the switch is not so easy because of LAPIC specifics, and it is meaningless to use LAPIC in that case. If you need to run C3 - turn LAPIC off. -- Alexander Motin