Re: [RFC/RFT] calloutng

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