From owner-freebsd-current@FreeBSD.ORG Wed Jan 2 22:06:18 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 43B89B05; Wed, 2 Jan 2013 22:06:18 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ea0-f181.google.com (mail-ea0-f181.google.com [209.85.215.181]) by mx1.freebsd.org (Postfix) with ESMTP id 272BC742; Wed, 2 Jan 2013 22:06:16 +0000 (UTC) Received: by mail-ea0-f181.google.com with SMTP id k14so5830467eaa.26 for ; Wed, 02 Jan 2013 14:06:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=3EcKGr55zw6+/irtMq+g7UAr+0y89PXbs2Myu69P0YQ=; b=Tv8eLhy6bKcOnHGEpyLTNFPl+wJaa2eKk4/HAH1XsZZE4Gwv21IwvSTBvEIhkDBL8s 1yssBkVYX9kSyeHoev85Q3s3HeNMXNtSH2DzX38QxtR6vw47RlAB93FE2LlA2T0jEAAp eQmqdTCMC0vEsNg1UrG37axDth1r4lG2CidlwvcH8ca+AQuZWFY5U6pCRbrV7PEVFu8W uIPuN090Wg0q3mE9mTcU5jsBxDFT1xtIetBH+BSQSurcEH/ixhxV04t2GDbKgqJY3bim eB/1j6yFuy0WVLYPE6B7q/0oBHFmvH7DG/QpvS6stDrkrfvL8fOWSbnzN4Dh8UJangIY dWyA== X-Received: by 10.14.0.133 with SMTP id 5mr127300082eeb.29.1357164370592; Wed, 02 Jan 2013 14:06:10 -0800 (PST) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id w44sm100140868eep.6.2013.01.02.14.06.07 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 Jan 2013 14:06:09 -0800 (PST) Sender: Alexander Motin Message-ID: <50E4AF4C.2070902@FreeBSD.org> Date: Thu, 03 Jan 2013 00:06:04 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: [RFC/RFT] calloutng References: <50CCAB99.4040308@FreeBSD.org> <50CE5B54.3050905@FreeBSD.org> <50D03173.9080904@FreeBSD.org> <20121225232126.GA47692@alchemy.franken.de> <50DB4EFE.2020600@FreeBSD.org> <1356909223.54953.74.camel@revolution.hippie.lan> <20121231061735.GA5866@onelab2.iet.unipi.it> <50E16637.9070501@FreeBSD.org> <20130102105730.GA42542@onelab2.iet.unipi.it> <50E418EA.7030801@FreeBSD.org> <20130102122743.GA43241@onelab2.iet.unipi.it> <1357135374.54953.150.camel@revolution.hippie.lan> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Davide Italiano , Ian Lepore , Marius Strobl , FreeBSD Current , freebsd-arch@freebsd.org, Luigi Rizzo X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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: Wed, 02 Jan 2013 22:06:18 -0000 On 02.01.2013 18:08, Adrian Chadd wrote: > .. I'm pretty damned sure we're going to need to enforce a "never > earlier than X" latency. Do you mean here that we should never wake up before specified time (just as specified by the most of existing APIs), or that we should not allow sleep shorter then some value to avoid DoS? At least on x86 nanosleep(0) doesn't allow to block the system. Also there is already present mechanism for specifying minimum timer programming interval in eventtimers(9) KPI. > Is there a more detailed writeup of calloutng somewhere, besides > David's slides? The wiki page is rather empty. There are updated manual pages in the patch. Also Davide written some blog during GSoC. Now we are working on papers for the AsiaBSDCon. > Eg - I think this work does coalesce wakeups, right? Or it can? So > when in low-power scenarios you can end up with lower-resolution > callout periods, but many less CPU wakeups a second? This work does coalesce wakeups out of the box, but also provide ways to improve it further, where possible. With additional tuning of some kernel subsystems and drivers I was able to drop total idle interrupt rate down to 10-15Hz on arm and 20-30Hz on x86. > (Do we actually _expose_ wakeups-per-second somewhere?) On systems with ACPI there are average per-CPU sleep times exposed via sysctls dev.cpu.X.cx_usage. Also cpu_idle() call rate calculated by both schedulers for purposes of idle loop optimizations, but it is not exposed outside now. Also for idle SMP system enabling COUNT_IPIS should give number of interrupts in systat comparable to number of wakeups. I am mostly using the last way. -- Alexander Motin