From owner-freebsd-arch@FreeBSD.ORG  Thu Jan  3 08:42:25 2013
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115])
 by hub.freebsd.org (Postfix) with ESMTP id 5737B333;
 Thu,  3 Jan 2013 08:42:25 +0000 (UTC)
 (envelope-from luigi@onelab2.iet.unipi.it)
Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238])
 by mx1.freebsd.org (Postfix) with ESMTP id 06BBB6CF;
 Thu,  3 Jan 2013 08:42:24 +0000 (UTC)
Received: by onelab2.iet.unipi.it (Postfix, from userid 275)
 id C099A7300A; Thu,  3 Jan 2013 09:41:26 +0100 (CET)
Date: Thu, 3 Jan 2013 09:41:26 +0100
From: Luigi Rizzo <rizzo@iet.unipi.it>
To: Kevin Oberman <kob6558@gmail.com>
Subject: Re: [RFC/RFT] calloutng
Message-ID: <20130103084126.GC54360@onelab2.iet.unipi.it>
References: <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>
 <CAO4K=PUHAH=UNzMde0V2TwkN5vj3gw9hHj5yCQxDvdUn+uqv7w@mail.gmail.com>
 <1357135374.54953.150.camel@revolution.hippie.lan>
 <CAJ-Vmo=mmm5zhwHyzKeg1VEL8hSz6_LxJAaLh74ArHF3_9KWaQ@mail.gmail.com>
 <50E4AF4C.2070902@FreeBSD.org>
 <CAN6yY1vRJN8EpKpYARfkShRzmPfC4VEw33O1mfppZ+D+8iebgQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAN6yY1vRJN8EpKpYARfkShRzmPfC4VEw33O1mfppZ+D+8iebgQ@mail.gmail.com>
User-Agent: Mutt/1.4.2.3i
Cc: Davide Italiano <davide@freebsd.org>,
 Ian Lepore <freebsd@damnhippie.dyndns.org>, Adrian Chadd <adrian@freebsd.org>,
 Alexander Motin <mav@freebsd.org>, freebsd-arch@freebsd.org,
 FreeBSD Current <freebsd-current@freebsd.org>,
 Marius Strobl <marius@alchemy.franken.de>
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Discussion related to FreeBSD architecture <freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-arch>,
 <mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
 <mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Jan 2013 08:42:25 -0000

On Wed, Jan 02, 2013 at 09:52:37PM -0800, Kevin Oberman wrote:
> On Wed, Jan 2, 2013 at 2:06 PM, Alexander Motin <mav@freebsd.org> wrote:
> > 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.
> 
> I can see serious performance issues with some hardware (wireless
> comes to mind) if things happen too quickly. Intuition is that it
> could also play hob with VMs.
> 
> I believe that the proper way is to wake between  T_X and T_X + D.
> This assumes that D is max_wake_delay, not deviation, which leaves us
> at the original of (T_X) =< event_time =< (T_X + D).

i think "max delay" was the intended meaning of the D parameter.
We picked bad names (tolerance, deviation,...) for it.

cheers
luigi