Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 05 Mar 2013 10:41:17 +0200
From:      Alexander Motin <mav@FreeBSD.org>
To:        Luigi Rizzo <rizzo@iet.unipi.it>
Cc:        Davide Italiano <davide@FreeBSD.org>, arch@freebsd.org
Subject:   Re: tickless design guidelines
Message-ID:  <5135AFAD.70408@FreeBSD.org>
In-Reply-To: <20130305080134.GC13187@onelab2.iet.unipi.it>
References:  <20130305080134.GC13187@onelab2.iet.unipi.it>

next in thread | previous in thread | raw e-mail | index | archive | help
On 05.03.2013 10:01, Luigi Rizzo wrote:
> Hi,
> i would like a bit of advice on how to get coarse time estimates
> (such as "no need to do anything unless at least X msec have elapsed")
> in a tickless kernel.
> 
> In the past (and I mean a distant one, i got this habit back in 2.x),
> rather than calling get*time(),  i used to look at "ticks" to
> see if it had changed, and only fetch the actual time accordingly.
> 
> This worked well with HZ=1000 or above, when my required accuracy
> a few milliseconds. With tickless kernels, i am not sure anymore
> how often ticks gets updated.
> 
> I may need to do this tests quite frequently (e.g. up to a million
> times per second), so I'd rather have some lightweight function.

At this point each active CPU still executes hardclock() with HZ rate as
before, skipping only ticks when CPU is idle. As result, both ticks and
getbinuptime() are working as before. First -- giving resolution of
1/HZ, second -- min(1/HZ, 1ms). The only place where it is unreliable to
use them is hardware interrupt handlers (not interrupt threads), as if
they fire during a long idle period timers may not be updated yet.

Another way that may be better then polling is to let callout(9) manage
time events. You can specify desired time and precision, and depending
on precision it will use either binuptime(), or getbinuptime(), or fast
custom way equivalent to ticks. Recent tests show that on x86 with LAPIC
timer and TSC timecounter present code can handle up to 600K event per
second from user-level on one core. From kernel I think rate could be
even higher.

-- 
Alexander Motin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5135AFAD.70408>